Environment
Server:
Client:
- Novell BorderManager 3.8.4
- Novell NetWare 6.5 Service Pack 5
Client:
- Microsoft Windows 2000
- Self written Windows database application Client
Situation
Database Application Client running on a Windows 2000 workstation
stops communicating through TCP generic proxy based on proxy adding
a PUSH flag to a data segment
As soon as the Windows 2000 client uses the generic TCP proxy in the communication path the client application crashes on receiving data from the server. This seems to be based on the amount of data returned back from the server (measured in rows, records returned to the client). Receiving Up to 18 rows of data works fine more than 18 rows of data crashes the client. If the client does not have any proxy in the communication path the application works without nay kind of problem.
Using a static NAT instead of the generic proxy server works fine as well but can not be used as a workaround based on the fact that this BorderManager server runs as well dynamic NAT which creates a look for internal clients using the database application
As soon as the Windows 2000 client uses the generic TCP proxy in the communication path the client application crashes on receiving data from the server. This seems to be based on the amount of data returned back from the server (measured in rows, records returned to the client). Receiving Up to 18 rows of data works fine more than 18 rows of data crashes the client. If the client does not have any proxy in the communication path the application works without nay kind of problem.
Using a static NAT instead of the generic proxy server works fine as well but can not be used as a workaround based on the fact that this BorderManager server runs as well dynamic NAT which creates a look for internal clients using the database application
Resolution
This issue has been addressed to engineering and will be fixed in
TCPIP version 6.81.01.
Additional Information
Looking into LAN traces taken at the BorderManager Proxy server
turns out that the problem is related to the fact that the
BorderManager server adds an extra TCP Push FLAG to data a
segment of 2030 bytes (20 rows of
data). The Data segment of 2030 bytes gets sent out by the application server in two TCP segments:
==========================================================
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 570 Bytes With_Push_Flag
BorderManager forwards these packets
Segment_1 = 1460 Bytes With_Push_Flag
+ Segment_2 = 570 Bytes With_Push_Flag
==========================================================
This behavior is different if the second segment sent by the application server is smaller If the server sends 18 rows of data the result will be a data segment passed down to TCP of 1830 bytes which will
==========================================================
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 370 Bytes With_Push_Flag
BorderManager for wards these packets
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 370 Bytes With_Push_Flag
==========================================================
data). The Data segment of 2030 bytes gets sent out by the application server in two TCP segments:
==========================================================
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 570 Bytes With_Push_Flag
BorderManager forwards these packets
Segment_1 = 1460 Bytes With_Push_Flag
+ Segment_2 = 570 Bytes With_Push_Flag
==========================================================
This behavior is different if the second segment sent by the application server is smaller If the server sends 18 rows of data the result will be a data segment passed down to TCP of 1830 bytes which will
==========================================================
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 370 Bytes With_Push_Flag
BorderManager for wards these packets
Segment_1 = 1460 Bytes No_Push_Flag
+ Segment_2 = 370 Bytes With_Push_Flag
==========================================================