CF sockets not "seeing" data that is there

  • Thread starter Thread starter Dag Liodden
  • Start date Start date
D

Dag Liodden

Hi all,

We've been experiencing some really strange behaviours on
sockets in CF (tested with SP1 and SP2). The problem occurs
when connecting via a GPRS link (works with cradle and
CSD). We know that data has been sent to the client, but
Socket.Poll(x, SelectMode.SelectRead) returns false
nevertheless.

Initially we started using Socket.Poll instead of blocking
reads as the blocking reads seem to have the same problem
with detecting available data and thus never returns until
the socket is shut down and we then needed to let the user
be able to cancel the transfer. Anyways, that clearly
didn't solve the problem.

The behaviour is very hard to reproduce consistently and we
know that tuning the buffer-size for Receive and the Poll()
interval changes the results. We do, however see lockups at
regular places in the transfer when transferring the same
data batch repeatedly.

This behavious has not been seen in our native apps, so we
believe that there's something up with the Compact
Framework, but cannot guarantee it.

We have only tested with QTek's / XDA's and various radio
stack / ROM versions (even a preview of Mobile 2003) and
the problem occurs in all of them.

Here's a snippet that will reproduce the error on our
devices when run 3-4 times with a data batch of about 7-8k
(not run in the GUI thread, of course):

private int Receive(byte[] buffer) {
int recvCount = 0;
int size = buffer.Length;
while (true) {
CheckCancelled();
if (sock.Poll(50000, SelectMode.SelectRead)) {
recvCount = sock.Receive(buffer, 0, sock.Available >
size ? size : sock.Available, SocketFlags.None);
if ((recvCount) == 0) throw new IOException("Connection
closed");
return recvCount;
}
}
}

Does anyone have clue? This is getting extremely
frustrating. :)

Cheers,

Dag
 
Dag:

Not sure if this will help - but I used up a support incident to get sockets
working for my Pocket PC CF app.

Trying to change receive time-out, send time-out, or even the no-delay
option all threw "unsupported" exceptions.
What was suggested by MS and finally worked for me was socket.select (even
though I'm only using one socket - socket.poll did not work for me either,
this app also uses a background non-gui thread for the receive)

The time (milliseconds) to wait parameter did not seem to work, so I always
set it to 1 ms. and put a sleep on the caller if the count comes back as
zero.

public int ReceiveNonBlocking(byte[] buffer, Socket socket)
{
int recvCount = 0;
ArrayList pollListRead = new ArrayList();
pollListRead.Add(socket);
Socket.Select(pollListRead,null,null,1);
if (pollListRead.Count > 0)
recvCount = socketReceive(buffer);
return recvCount;
}

The same was true for UDP communication. Socket.Select let me know if data
was available, which I could I follow up with socket.ReceiveFrom.

Hope this helps
Jim

Dag Liodden said:
Hi all,

We've been experiencing some really strange behaviours on
sockets in CF (tested with SP1 and SP2). The problem occurs
when connecting via a GPRS link (works with cradle and
CSD). We know that data has been sent to the client, but
Socket.Poll(x, SelectMode.SelectRead) returns false
nevertheless.

Initially we started using Socket.Poll instead of blocking
reads as the blocking reads seem to have the same problem
with detecting available data and thus never returns until
the socket is shut down and we then needed to let the user
be able to cancel the transfer. Anyways, that clearly
didn't solve the problem.

The behaviour is very hard to reproduce consistently and we
know that tuning the buffer-size for Receive and the Poll()
interval changes the results. We do, however see lockups at
regular places in the transfer when transferring the same
data batch repeatedly.

This behavious has not been seen in our native apps, so we
believe that there's something up with the Compact
Framework, but cannot guarantee it.

We have only tested with QTek's / XDA's and various radio
stack / ROM versions (even a preview of Mobile 2003) and
the problem occurs in all of them.

Here's a snippet that will reproduce the error on our
devices when run 3-4 times with a data batch of about 7-8k
(not run in the GUI thread, of course):

private int Receive(byte[] buffer) {
int recvCount = 0;
int size = buffer.Length;
while (true) {
CheckCancelled();
if (sock.Poll(50000, SelectMode.SelectRead)) {
recvCount = sock.Receive(buffer, 0, sock.Available >
size ? size : sock.Available, SocketFlags.None);
if ((recvCount) == 0) throw new IOException("Connection
closed");
return recvCount;
}
}
}

Does anyone have clue? This is getting extremely
frustrating. :)

Cheers,

Dag
Click to expand...
 
Back
Top