void SendUDPstr(char *str, IPADDR DSTADDR){
UDPPacket pkt;
pkt.SetSourcePort(12345);
SetDestinationPort(54321);
pkt.AddData(str);
pkt.Send(DSTADDR);
return;
}
I have been using a Semaphore to protect access to the above code, is it nessesary? If the semaphore is nessesary is there a better way?
Thanks,
Ron Neal
UDP question
Re: UDP question
I do not think you need any protections for this function. Protection will only be required if some other task or interrupt will be modifying the same string you pass to this function.
Re: UDP question
The reason I ask is that I am losing some UDP packets "if" they are sent too quickly. I can't tell if they have all been sent or if the problem is on the "client's" end. If I place OSTimeDly(1) at the end of the SendUDPstr function there is no problem. The missing UDP packets do not present a huge problem, if it did I would use TCPIP. I would just like to understand what is going on.
Thanks,
Ron
Thanks,
Ron
Re: UDP question
How many packets are you trying to send at once? I think there is a good chance you are trying to send too many packets at the same time and all the buffers are being used up. OSTimeDly(1) would fix this problem since the NetBurner can send way more then 20 packets a second... the NetBurner can actually send thousands of packets a second, close to 90mbit transmit with UDP. Still a loop with no delays can create more packets then the NetBurner can send which will eventually result in no buffer being allocated when you create a UDP object.
First thing I would do is confirm the NetBurner is not sending the packets. You can run wireshark on the machine receiving the packets. This will show if the PC is really not getting the packets or if the application is just missing them.
You can also modify the UDPPacket constructor in UDP.cpp:
UDPPacket::UDPPacket()
The first thing this constructor does is a GetBuffer(); call. If this fails it just returns, you may want to add a debug print here and you will be able to see if you are running out of buffers.
You may want to use the following function to check the buffer count on the NetBurner side:
#include <buffers.h>
WORD GetFreeCount();
This number should never be lower then 10 or so, it should probably be way over 100 most of the time. If it is at 0 you will not be able to allocate a buffer for any network functions, including new UDP packets.
After you create a UDP packet you can check if there is an actual buffer reserved a few ways. The first thing you do is set the source port, you can try reading this back right after to see if it is stored properly:
WORD UDPPacket::GetSourcePort()
If you were never allocated a buffer then this should always return 0, otherwise it will return the source port you just configured it to.
First thing I would do is confirm the NetBurner is not sending the packets. You can run wireshark on the machine receiving the packets. This will show if the PC is really not getting the packets or if the application is just missing them.
You can also modify the UDPPacket constructor in UDP.cpp:
UDPPacket::UDPPacket()
The first thing this constructor does is a GetBuffer(); call. If this fails it just returns, you may want to add a debug print here and you will be able to see if you are running out of buffers.
You may want to use the following function to check the buffer count on the NetBurner side:
#include <buffers.h>
WORD GetFreeCount();
This number should never be lower then 10 or so, it should probably be way over 100 most of the time. If it is at 0 you will not be able to allocate a buffer for any network functions, including new UDP packets.
After you create a UDP packet you can check if there is an actual buffer reserved a few ways. The first thing you do is set the source port, you can try reading this back right after to see if it is stored properly:
WORD UDPPacket::GetSourcePort()
If you were never allocated a buffer then this should always return 0, otherwise it will return the source port you just configured it to.
Re: UDP question
FYI. My network analyzer program showed that my cfv2-40 was sending all of the UPD packets correctly. The problem is with the client which is a C# GUI program running under XP Professional.
Thanks again for the info,
Ron
Thanks again for the info,
Ron