RSocket, UDP, RecvFrom and WLAN

[MKechlibar]

I am using a RSocket to connect to a remote server. I am sending and receiving UDP packets (the protocol is SIP and RTP).

I am aware about the fact that UDP sockets are connectionless, and therefore do not need a Connect() before using RecvFrom and SendTo.

Nevertheless, I have experienced the following strange behavior on Nokia E90 Communicator, when I connect the socket over WLAN:

- if I use Connect() on the socket before, the connection is relatively reliable, and I can do multiple SendTo()/RecvFrom() calls on the socket,

- if I do not use Connect(), the first RecvFrom() returns, but the next RecvFrom() never returns, even though the remote server sends me data.

This does not happen over GPRS, and it does not happen on the Emulator.

Should I use any flags like KSIPseudoStream, KSIUrgentData, KSICanReconnect and similar?

I want to use the sockets for VoIP, using protocols SIP, RTP, SRTP, ZRTP.

[wizard_hu_]

I am using UDP in ad-hoc WLAN setting for years by now, and it just works, both for unicast and broadcast.
In an IMS related project UDP also worked as SIP transport, with the built-in SIP stack.
The environment includes an E90 too, its firmware is 7.40.1.2, so it is far from the latest one (http://wiki.forum.nokia.com/index.ph...mware_Versions).

Try using some network monitoring tool.

[MKechlibar]

I am using UDP in ad-hoc WLAN setting for years by now, and it just works, both for unicast and broadcast.
In an IMS related project UDP also worked as SIP transport, with the built-in SIP stack.
The environment includes an E90 too, its firmware is 7.40.1.2, so it is far from the latest one (http://wiki.forum.nokia.com/index.ph...mware_Versions).

Try using some network monitoring tool.

Can you recommend some Symbian-based tool to me? Wireshark etc. do not run on Symbian OS AFAIK. I have tried Ping only. Ping ran with latencies from 100 to 700 ms, but with almost no timeouts.

My RSocket/UDP usage seems to be plagued by problems on real devices.

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 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?

[wizard_hu_]

Can you recommend some Symbian-based tool to me? Wireshark etc. do not run on Symbian OS AFAIK. I have tried Ping only. Ping ran with latencies from 100 to 700 ms, but with almost no timeouts.

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.

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?

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?

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?

I really do not know, here is my complete UDP code:

void CSocketActive::SetupSocketL(const TDesC &aIP)
{
	User::LeaveIfError(iSocket.Open(iServ,KAfInet,KSockDatagram,KProtocolInetUdp,iConnection));
	iSendAddr.SetAddress(KInetAddrAny);
	iSendAddr.SetPort(5566);
	User::LeaveIfError(iSocket.Bind(iSendAddr));
	iSendAddr.Input(aIP);
}

void CSocketActive::StartSend()
{
	iSocket.SendTo(iSendElement,iSendAddr,0,iStatus);
	SetActive();
	iState=ESend;
}

void CSocketActive::StartRecv()
{
	iSocket.RecvFrom(iRecvElement,iRecvAddr,0,iStatus);
	SetActive();
	iState=ERecv;
}

[MKechlibar]

So, you do not perform RecvFrom() and SendTo() on the same instance of RSocket at the same time?

I have 2 CActive objects, therefore 2 iStatus-es, and I perform these operations simultaneously. Could this be the problem?

(In protocol like RTP, where around 50 packets are sent and 50 are received every second, this came as natural to me).

Marian

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.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?I really do not know, here is my complete UDP code:

void CSocketActive::SetupSocketL(const TDesC &aIP)
{
	User::LeaveIfError(iSocket.Open(iServ,KAfInet,KSockDatagram,KProtocolInetUdp,iConnection));
	iSendAddr.SetAddress(KInetAddrAny);
	iSendAddr.SetPort(5566);
	User::LeaveIfError(iSocket.Bind(iSendAddr));
	iSendAddr.Input(aIP);
}

void CSocketActive::StartSend()
{
	iSocket.SendTo(iSendElement,iSendAddr,0,iStatus);
	SetActive();
	iState=ESend;
}

void CSocketActive::StartRecv()
{
	iSocket.RecvFrom(iRecvElement,iRecvAddr,0,iStatus);
	SetActive();
	iState=ERecv;
}

[wizard_hu_]

Yes, I do. I was focusing on showing that I am not aware of any special configuration magic.
The real code is as follows

void CSocketActive::StartRecv()
{
	iSocket.RecvFrom(iRecvElement,iRecvAddr,0,iHelper->iStatus);
	iHelper->SetActive();
	iRecvState=ERecvRecv;
}

where iHelper is a CActive exposing its methods publically (SetActive would be protected by default), and calling back its user via "HelperRunL" and "HelperDoCancel".
Regardless of the protocol (TCP, UDP, RFCOMM), I always have a read request outstanding.