A part of my OpenAT application uses TCP socket to send data. The socket is kept open as long as possible.
For test purposed I send a numbered packet of data every 10s. AT the start I receive sent data as expected. Then the data stops comming and is buffered somewhere. When the buffer is full ( 536B size of GPRS packet or multiple of it) it is received by TCP socket server as listed in the log below.
2008-01-24 15:29:28.968 00214:Packet from Q2686H
2008-01-24 15:29:39.015 00215:Packet from Q2686H
2008-01-24 15:29:49.031 00216:Pakiet z Q2686H
// — no data being transmitted for over 4 minutes beside the fact that everything seems to be ok —
2008-01-24 15:34:09.578 00217:Packet from Q2686H00218:Packet from Q2686H00219:Packet from Q2686H00220:Pack…et from Q2686H00242:Packe //(536B of data, not a single character is lost)
2008-01-24 15:34:09.937 t from Q2686H
2008-01-24 15:34:19.328 00243:Packet from Q2686H
2008-01-24 15:34:29.421 00244:Packet from Q2686H
The problem is that I don’t get any indication that the TCP data is not actually being transmitted.
I use:
wip_state = wip_getState(tcp_WipHandle);
to receive the socket state, but it returns:
wip_state == WIP_CSTATE_READY
even when the problem occurs.
The acctual data transmission is done by:
len = wip_write( tcp_WipHandle, tcp_DataBuffer, tcp_DataLength);
but it also returns:
len == tcp_DataLength
even when the problem occurs.
This application is being tested on OpenAT 3.17 and Fastrack M1306B with 6.57e firmware as well as on OpenAT 4.22a and Q2686H with 6.63 firmware. On both devices results were the same. If I use both devices at the same time, data received form one of the devices confirmes that the socket server is still up while transmission from the other one is buffered. I’ve also noticed that this problem is network related since once a while data from both devices starts to be buffered exacly at the same time regardles of the time devices where turned on.
Any suggestions what may cause this to happen and how to solve it without confirmations from TCP socket server?
I have no problems with TCP on my Q2686. Are you sure to be compliant with data sending/reception
and event reporting? Are you checking ev->content.read.readable value? Check in manual for WIP
how WIP_CEV_WRITE and WIP_CEV_READ works (buffering methodology).
I’m just sending the data, so only WIP_CEV_WRITE event is relevant.
This event takes place after creating a socket and since each data chunk is relatively small it is never triggered again (value returned by wip_write( tcp_WipHandle, tcp_DataBuffer, tcp_DataLength) == tcp_DataLength and all the data is sent with single socket creation until an error or disconnection).
As I understand checking ev->content.write.writtable value is needed after WIP_CEV_WRITE following the situation when not all data has been sent (wip_write returns 0 or value < tcp_DataLength).
I call wip_write whenever (every 10s in this test procedure) there is new data to be sent without establishing new socket to receive WIP_CEV_WRITE.
As mentioned earlier I’m just checking wip_getState(tcp_WipHandle) to return WIP_CSTATE_READY and the value returned by wip_write to be the data length which obviously not enough. Is there something I’m missing? Should I check something else?
Now, your description of sending side seems to be ok. What about other side? Again, are you
compliant with data reception? If this is not a problem, paste here your event handler or only
switch case on WIP_CEV_READ. I suspect what can be wrong.
The other side is a TCP socket server on PC. Since the buffered data size is always 536B or multiple of it I assume, that the buffering is somewhere before it leaves the GSM infrastructure. I mentioned that I use two devices for test purposes, but they don’t communicate with each other. It’s a one-way transmission.
Behavior that yous see is completely normal for socket communication.
If the server can not be reached (temporary loss of network connection) client starts to buffer the data and
you get error when the buffer is full.
Only way to be sure that the data client sends reaches the server is to
send acknowledgment from the server.
Did you ever resolve this buffering issue ? The reason I ask is that I’m seeing exactly the same thing using a 2686, also sending small packets of data. The problem is very inetermittent. I’ve tried enabling the WIP_COPT_NODELAY option but this makes no difference. I’m currently working with a TCP/IP socket, but am starting to wonder if a UDP socket may be better in terms of avoiding these delays. Anyone have any ideas about this ?
Thanks,
Adrian
just a wild guess, but GPRS service providers have a strong incentive to make VoIP and other realtime streaming protocols completely impractical; and a simple way to make these impractical is to introduce buffering, thus lags, in the packets routing. Have you tried your application with a SIM from a different provider?
A potentially interesting test is to enable raw IP traces, to check when packets leave the module (I can’t remember the trace number, but it’s in the manual). By checking these and what’s received by the server (e.g. with ethereal/wireshark), you’ll know whether bufferings happen on the module, on the server, or somewhere in between.