I need to use udp because my application is an h323/sip endpoint. RTP uses udp sockets to transmit/receive audio/video data. RTCP can be used to manage packet loss.
OK, good.
But in this case packets are not lost by the network. If I use wireshark I can see all the packets.
I'll assume you use a direct cable or put wireshark at the receiving computer because sending a packet is not a problem. Having the packet reaching the network card of the receiving computer is a different thing if there is something in between.
Have you checked your network card is operating at 100 Mbps ?
I think that there is a problem in my code.
Probably. If your network was bad, you would already know it.
I know that gui messages can interfere with socket messages.
It is not the messages which interfere, but GUI message processing can be very slow compared to network messages and while a GUI message is processed, no other message of the same thread can be processed.
So I've created a worker thread that manage socket in its own message loop.
That's perfect. But be sure to avoid using Synchronize or to block your thread while the GUI handle your messages. You really have the thread pumping messages as fast as possible. Just read the UDP socket and put the message in a queue for the GUI thread, then signal the GUI that the queue has a new message and let the thread pump the next message.
Could be the problem in the way I create/use the message loop in worker thread? This is the execute method (DoInit create the socket):
Your code looks OK.
The DoInit method is called before AllocateHWnd, so the socket is created before. Could be here the problem?
No, it is OK.
It seems that the thread is not fast enought to elaborate socket messages.
Look at how your worker thread handle messages. As I said above, it has to be as fast as possible. Just receive the data into some kind of queue and signal it to the GUI thread without ever waiting for the GUI thread to handle the data.
Or that the gui slow the worker thread in some way.
If the GUI thread is CPU bound, then it will hog most of the CPU unless the workerthread has a higher priority.
If I call GetCurrentThreadID inside the DataAvailable the result is the id of the worker thread.
So the socket is correctly created.
The only thing done inside the DataAvailable callback is check packet number.
Probably not. At least you have to pass data to the GUI thread.
The cpu is used about 12%.
Good news.
I've tried to set the process priority (thank you Angus), but nothig changes.
What kind of performance do you reach using udp sockets? I think that my performance are not satisfactory.
Depending on your hardware, you should be able to handle 100 Mbps and more. If you write data to disk, this may slow down things. If you display data, this may slow down as well.
You may try a simple program which do nothing withe the data except checing the packet number and see how many packets you can receive.
One last note: Disable any firewall and security product to do your testing. Many of those security products are trapping network traffic and can slow down thruput and may have bugs. So in case of difficulties like you have, it is better to disable everything and use a bare bone clean computer setup. Of course later you'll turn security back on.
-- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
