Sending multiple data packets

Sending multiple data packets SearchSearch

SMS & MMS Technical Forum » Now.WAP Proxy (Product Support Only) » Sending multiple data packets « Previous || Next »
Author Message
Henrik Ole Hansen
New member
Username: Hoh

Post Number: 1
Registered: 06-2011
Posted on Tuesday, June 07, 2011 - 01:58 pm:   

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
Posted on Tuesday, June 07, 2011 - 03:53 pm:   

Hi Henrik,


quote:

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.




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
Posted on Wednesday, June 08, 2011 - 09:06 am:   

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.

Add Your Message Here, or click here to create a new discussion topic.
Post:
Bold text Italics Underline Create a hyperlink Insert a clipart image
Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Click here to create an account.
Username:
Password:
Options: Automatically activate URLs in message
Action:

Login Login / Register Logout Logout Search Last 30 Days Topics Topics