| Sending multiple data packets |  Search
|
|
NowSMS Support Forums ⬆ Now.WAP Proxy Support ⬆ |
◄ ► |
| Author | Message | |||
| Henrik Ole Hansen New member Username: Hoh Post Number: 1 Registered: 06-2011 |
I have a question regarding sending of data (packets) using NowWap. It currently takes approx. 34 seconds to send a response from the WAP Gateway to our devices. I think this is a network issue, but I want to be sure I’m reading the NowWAP debug log correctly. I’ve tried to write down a timeline describing what happens (taken from the debug log) when a device request a page. This particular test was done in a heavy loaded environment, so it seems some packets are not sent resulting in some retry’s: Seconds: Event (from debug log) 0: Start: device sends request (Device display = ‘Connecting…’) 2: WAP GW receives request (131 bytes) 2: WAP GW sends 183 bytes back to device (containing result url plus ‘Loading…’ text) 4: WAP GW receives ACK from device 5: WAP GW starts sending 6087 bytes to device 5: WAP GW sends 1400 bytes 6: WAP GW sends 1404 bytes 8: WAP GW sends 1404 bytes 10-21: ‘Retry packet send’ + ACK to/from device 21: WAP GW sends 1404 bytes 23: WAP GW sends 491 bytes (Device display = ‘Receiving…’) 26-31: ACK to/from device 34: Finished: Data shown on device As you can see, the device display says ‘Connecting…’ immediately after it has sent the request to the GW, but it doesn’t say ‘Receiving…’ before 23 seconds have passed. My question is: When is the data actually sent to the device? According to the log, it seems like data is sent continuously in packets after a couple of seconds (after 2 and 5 seconds in the timeline above). I’m assuming the device doesn’t display the current state of data transferring correctly, but I might be wrong. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3240 Registered: 08-2008 |
Hi Henrik,
That is what I would assume as well. You might want to use a packet sniffer like WireShark to confirm and better understand. But essentially what you see in the debug log is when the packets are being sent. What type of network are you using? Is this Tetra by any chance? For slower networks, the default ACK timeout can result in retries that can saturate the network and delay the ACK receipt. Here are some parameters that can be tuned: WTPSarAckTimeout=### When sending a segmented response to a client, this is the maximum number of seconds that the server will wait for an acknowledgment before aborting the response. The default value is 90 seconds. WTPSarAckTimeoutResend=### When sending a segmented response to a client, this is the maximum number of seconds that the server will wait for an acknowledgment for any segment that requires acknowledgment before resending the current segment. The default value is 8 seconds. WTPAckTimeout=### When sending a simple (non-segmented) response to a client, this is the maxmium number of seconds that the server will wait for an acknowledgment before aborting the response. The default value is 90 seconds. WTPAckTimeoutResend=### When sending a simple (non-segmented) response to a client, this is the maximum number of seconds that the server will wait for an acknowledgment of the response before resending the response. The default value is 5 seconds. WTPSarSegmentSize=#### This setting specifies the maximum segment size in bytes to be used in segmentation and reassembly (SAR) responses generated by the gateway. The default setting is 1400 bytes. WTPSarWindowSize=#### This setting specifies the window size (number of packets sent without acknowledgement) to be used in segmentation and reassembly (SAR) responses generated by the gateway. The default setting is 3. For a slower network, it is often necessary to adjust the WTPSarAckTimeoutResend setting. In particular, I seem to recall Tetra networks having a transmit speed of around 9600bps (and lower in the real world). This bps is bits per second, so you're looking at around 1000 bytes/characters per second at that speed. Best case scenario for three 1404 byte packets at that speed is around 4-1/2 seconds, plus latency for the ACK to be returned. Assuming real world speeds are lower, 8 seconds before resend is pushing it. Any resent packets may then slow down receipt of the ACK. As a result, this WTPSarAckTimeoutResend is often adjusted on Tetra networks. And sometimes the segment and window sizes as well. Of course, I'm going out on a limb assuming that this is a Tetra network, but the timings that you mention do appear to be in that type of speed range. -- Des NowSMS Support | |||
| Henrik Ole Hansen New member Username: Hoh Post Number: 2 Registered: 06-2011 |
Thank you for your help. You're correct, we're using a Tetra network. Increasing the WTPSarAckTimeoutResend setting helped on the packet resend. I found out that the device we're using changes the display to 'Receiving...' after the last segment has been sent, so the device continuously receives data. | |||
