# Wip\_write to TCP socket - unexpected buffering **URL:** \ **Category:** Open AT\ **Created:** [January 24, 2008, 3:30pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863 "2008-01-24T15:30:51Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jacfry](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jacfry](https://forum.sierrawireless.com/u/jacfry)\ **Post date:** [January 24, 2008, 3:30pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/1 "2008-01-24T15:30:51Z")
Hello, 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: ```auto wip_state = wip_getState(tcp_WipHandle); ``` to receive the socket state, but it returns: ```auto wip_state == WIP_CSTATE_READY ``` even when the problem occurs. The acctual data transmission is done by: ```auto len = wip_write( tcp_WipHandle, tcp_DataBuffer, tcp_DataLength); ``` but it also returns: ```auto 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? ---
**Author:** ![krutecki](https://avatars.discourse-cdn.com/v4/letter/k/8dc957/32.png) [@krutecki](https://forum.sierrawireless.com/u/krutecki)\ **Post date:** [January 24, 2008, 4:53pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/2 "2008-01-24T16:53:26Z")
Hi 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). \kr ---
**Author:** ![jacfry](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jacfry](https://forum.sierrawireless.com/u/jacfry)\ **Post date:** [January 24, 2008, 7:20pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/3 "2008-01-24T19:20:49Z")
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? ---
**Author:** ![krutecki](https://avatars.discourse-cdn.com/v4/letter/k/8dc957/32.png) [@krutecki](https://forum.sierrawireless.com/u/krutecki)\ **Post date:** [January 25, 2008, 8:17am UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/4 "2008-01-25T08:17:58Z")
Hi 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. \kr ---
**Author:** ![jacfry](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jacfry](https://forum.sierrawireless.com/u/jacfry)\ **Post date:** [January 25, 2008, 8:43am UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/5 "2008-01-25T08:43:47Z")
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. ---
**Author:** ![Kaldvee](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@Kaldvee](https://forum.sierrawireless.com/u/Kaldvee)\ **Post date:** [February 11, 2008, 6:53pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/6 "2008-02-11T18:53:09Z")
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. ---
**Author:** ![AdrianM](https://avatars.discourse-cdn.com/v4/letter/a/8edcca/32.png) [@AdrianM](https://forum.sierrawireless.com/u/AdrianM)\ **Post date:** [April 7, 2008, 9:47pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/7 "2008-04-07T21:47:53Z")
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 ---
**Author:** ![fft](https://avatars.discourse-cdn.com/v4/letter/f/e8c25b/32.png) [@fft](https://forum.sierrawireless.com/u/fft)\ **Post date:** [April 8, 2008, 5:31pm UTC](https://forum.sierrawireless.com/t/wip-write-to-tcp-socket-unexpected-buffering/1863/8 "2008-04-08T17:31:06Z")
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.