Re: [twsocket] UDP Receive problem
HI François Thanks for the advices Having two separet thread is not enough. You have to closely look at how the receiving thread communicate with the processing/display thread. For example if you use synchronize, you actually defeat the multithreading. Same with SendMessage. You must keep the message pump of the receiver thread run at full speed. I found the problem and I´m mad at my self!! The problem is that I was not setting the receive buffer size... But I have programmed it.. only for Listening state, when the socket enters on listen state I set the receive buffer and it always worked because I usually only use UDP sockets to listen, but I was making a particular implementation that I had to send UDP data on the same socket, so I used Connect method instead of Listen, so, when socket changed state, it was not setting the receive buffer size because it was only programmed to set the size when socket was Listening! Well... Silly Thanks a lot! Eric -- 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
Re: [twsocket] UDP Receive problem
I'm happy you finally found the problem. Thanks for your feeback. -- 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 - Original Message - From: Éric Fleming Bonilha e...@digifort.com.br To: ICS support mailing twsocket@elists.org Sent: Saturday, April 16, 2011 1:01 AM Subject: Re: [twsocket] UDP Receive problem HI François Thanks for the advices Having two separet thread is not enough. You have to closely look at how the receiving thread communicate with the processing/display thread. For example if you use synchronize, you actually defeat the multithreading. Same with SendMessage. You must keep the message pump of the receiver thread run at full speed. I found the problem and I´m mad at my self!! The problem is that I was not setting the receive buffer size... But I have programmed it.. only for Listening state, when the socket enters on listen state I set the receive buffer and it always worked because I usually only use UDP sockets to listen, but I was making a particular implementation that I had to send UDP data on the same socket, so I used Connect method instead of Listen, so, when socket changed state, it was not setting the receive buffer size because it was only programmed to set the size when socket was Listening! Well... Silly Thanks a lot! Eric -- 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 -- 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
Re: [twsocket] UDP Receive problem
HI François I thought on processing speed, but I use a separated thread for I/O communication and for testing I have only 1 socket and still dropping some packets. And for testing, at a given time, the processor usage is always 0%. The received data is not even large, I can notice drops in receiving just 20 packets of 1400 bytes of data. In any case, that would fit inside winsock buffer, even if my application is hang right? I also increased the winsock receive buffer to 256KB. Is there a limit of winsock receive buffer? Eric -Mensagem Original- From: Francois PIETTE Sent: Thursday, April 14, 2011 2:07 AM To: ICS support mailing Subject: Re: [twsocket] UDP Receive problem My application receives UDP data from IP Cameras, somehow we are not receiving some packets, but by using a network sniffer I can see that the packet was received, but the application never receives it! I already checked receive buffer lengths.. I actually spent 2 entire days cheking for solutions but I couldn´t find anything At first glance, I would say that your receiving application is not able to receive the datagrams as fast as they are comming. So they are simply dropped from winsock buffer as new datagrams are comming in. I suggest you use a different thread for the newtork I/O (TWSocket) and for the computation and display. Let's name the thread with TWSocket a worker thread. The worker thread can be assigne high priority and build a large buffer to store datagrams until the main thread is able to process it. Pay attention to not use anything taking time ! Specially, do not use Synchronize. Of course you need a critical section to have the main thread and worker thread to acces the queue at the same time. Pay a lot of attention to the duration of the lock, make it as small as possible or you are back to your initial issue. Also note that this design will potentially cause trouble if the overall computation and display time is slower than the average network I/O speed, the your buffer will grow. At some time you'll be forced to drop datagrams yourself to avoid accumulating data. Another possibility is that you have a bug in your application which makes some datagrams unprocessed. Yest another possibility is that you have a security product which is bugged or takes too long to process. Many security product intercept the network I/O to check for malware. -- 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 -- 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
[twsocket] UDP Receive problem
Hi I´m experiencing a very weird problem and I hope someone can help me My application receives UDP data from IP Cameras, somehow we are not receiving some packets, but by using a network sniffer I can see that the packet was received, but the application never receives it! I´m using TWSocket to receive UDP data I already checked receive buffer lengths.. I actually spent 2 entire days cheking for solutions but I couldn´t find anything Have anybody already experienced something like this? Thanks Eric -- 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
Re: [twsocket] UDP Receive problem
My application receives UDP data from IP Cameras, somehow we are not receiving some packets, but by using a network sniffer I can see that the packet was received, but the application never receives it! I already checked receive buffer lengths.. I actually spent 2 entire days cheking for solutions but I couldn´t find anything At first glance, I would say that your receiving application is not able to receive the datagrams as fast as they are comming. So they are simply dropped from winsock buffer as new datagrams are comming in. I suggest you use a different thread for the newtork I/O (TWSocket) and for the computation and display. Let's name the thread with TWSocket a worker thread. The worker thread can be assigne high priority and build a large buffer to store datagrams until the main thread is able to process it. Pay attention to not use anything taking time ! Specially, do not use Synchronize. Of course you need a critical section to have the main thread and worker thread to acces the queue at the same time. Pay a lot of attention to the duration of the lock, make it as small as possible or you are back to your initial issue. Also note that this design will potentially cause trouble if the overall computation and display time is slower than the average network I/O speed, the your buffer will grow. At some time you'll be forced to drop datagrams yourself to avoid accumulating data. Another possibility is that you have a bug in your application which makes some datagrams unprocessed. Yest another possibility is that you have a security product which is bugged or takes too long to process. Many security product intercept the network I/O to check for malware. -- 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
