Jon Mansey wrote:
>You will probably want to tweak the stack on the receivers more than
>the senders as this is where the bottleneck happens due to windows
>woefully small TCP window size.
Yes, but the receive window size can be set to a specific (larger) value using a registry key. Another key can be used to force the window scaling option but this IS enabled by default. If the window size set is larger than the 64KB limit then, "...Windows attempts to use a scale value that accommodates the new window size." [see link] This information relates only to Microsoft Windows 2000.
see: http://support.microsoft.com/support/kb/articles/Q224/8/29.ASP for full information.
Andrew Pether
>All:
>
>Please excuse this post if inappropriate.
>
>Am seeking any interest in an opportunity to test research
>projects/products in a working satellite environment: am working on a US
>Federal telehealth project in the state of Alaska -- we have a statewide
>network interconnected by a combination of satellite-based and terrestrial
>T1 and sub-DS1 links. We have developed a web-based application for
>digital acquisition of medical imagery in remote areas, with a
>store-and-forward function for referral of medical data to distant
>providers/specialists. The application has been developed on Win2K
>platforms (both client and server) using ColdFusion middleware and SQL
>database backends. I am currently porting the application to Linux.
>
>We have run into the well-known snag with sat links and TCP: short bursty
>data transfers over TCP don't do so well on high-band/long delay nets.
>
>I am seeking information related to Open Source TCP stack modifications
>for a web proxy to be placed on the web server LAN in order to accelerate
>the transfer of data out over the WAN to distant client machines. We do
>*NOT* want to modify the stack on the webserver itself, but on an
>accelerating proxy for outlying satnet clients.
>
>Our network is private, e.g. is NOT connected to the public Internet. We
>are built out on RFC 1918 address space, use Cisco network elements and
>standard transport offerings from Alaska-based space segment providers.
>
>If anyone on this list has an interest in testing within such an
>environment (whether your solution is commercial or non-commercial) we
>would like to speak with you. We are, as stated, seeking non-commercial
>Open Source variants of standard TCP implementations -- primarily on the
>sender side. Link layer framing is typically standard serial, as
>ATM-based cell protocol offerings in the Alaska market were recently
>pulled by AT&T (e.g. we use HDLC, PPP, etc.)
>
>I am particularly interested in any TCP mods that have been developed for
>BSD-derived unices.
>
>Please contact:
>
>Thomas Bohn
>Alaska Federal Healthcare Access Network (AFHCAN) Project
>c/o AFHCAN Telecom and Networking
>907.729.2266
>[email protected]
>
>reference: http://www.afhcan.org --> this site in progress of update, so
>please check back more than once in the coming weeks.
>
>Thanks!
This archive was generated by hypermail 2b29 : Fri Feb 02 2001 - 10:20:00 EST