Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Reassembly timeout limit on Win2K and Win XP

3 views
Skip to first unread message

Peleg@discussions.microsoft.com Tomer Peleg

unread,
Sep 21, 2009, 11:08:09 AM9/21/09
to

Hello,

We have developed a communication system which is composed of two parts:
Application layer, and Data link layer.
The two layers are developed as two different systems. The application layer
is developed using a standard PC, running a Win2K or Win XP operating systems.

The data link supports UDP-IP as the communication protocol. Due to the size
of the messages, and the time it takes the data link to transfer the
messages, it takes a single message more than 60 seconds from the time the
first IP packet is been received to the last IP packet (The entire UDP
message).

Due to the Reassembly time out limitation of the operating system in the
receiving station, the application layer does not receive the message.
We have changed the IpReassemblyTimeout in the registry (under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) to be
180 seconds (D4 hex value).
We found out that despite the change we made, the actual Reassembly time out
is limited to around 120 seconds (trial and error).
We would like to know the following:
1. Is there a Reassembly time out maximum value ? What is the limitation?
2. Is there a way to overcome this limitation?
3. Are there any other parameters that are relevant to the reassembly
mechanism?

Thank you for your help,
Tomer Peleg,
Senior communication system engineer
Elbit Systems limited

Amlah@discussions.microsoft.com K. Amlah

unread,
Oct 22, 2009, 2:28:01 PM10/22/09
to
This is a security constraint (like you said). Reducing this value is
possible but increasing it beyond 60 is impossible. This is Windows specific
and has nothing to do with the protocol (timeout periods are not a part of
the specification in the UDP standard), so on Linux for example, this would
not have been a limitation.

Your only option is to work directly with the network subsystem (either the
NDIS or TDI layers). There are many SDK's available for this out there.

0 new messages