I am not aware of such tool neither, however a packet sniffer does not have to be running on the endpoints. If the device itself would receive packets, probably your application would receive them too. A sniffer would show if the packets leave the server at all.
Originally Posted by MKechlibar
You mean delays? The concept of 'connection timeout' is hard to interpret in the context of a connection-less protocol. Otherwise several seconds of delay seems to be unusual in a local WLAN test environment. What happens if you try your server with a PC-based VoIP client?
In VoIP software, one generally needs two sockets: an UDP socket for SIP connection and an UDP socket for RTP connection. The former needs to be connected for a longer time, the latter for duration of the call.
However, my RSockets are plagued by unpredictable timeouts (> several seconds), over both WLAN and GPRS/EDGE. Is that normal in real devices?
I really do not know, here is my complete UDP code:
I wanted to get rid of the problem by removing the Connect() operation of the RSocket, and I ran straightly into the problem described in the first post: only the first RecvFrom() works for me.
Can I use some flags or some priorities in order to improve timeout behavior of a RSocket?
void CSocketActive::SetupSocketL(const TDesC &aIP)