HDTenEightyP/NetNews huggingface dataset:
From: tga@oar.net (Germann Associates)
Subject: Re: IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!
Keywords: TCP-IP DOS OS/2 memory
Organization: Ohio Academic Resources Network
Date: Mon, 25 Jan 1993 05:31:09 GMT

In article <alen.727807438@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes:
>I'm in a bind...
>
>I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers)
>I have an application that runs on a LAN (IBM Adaptor card) under OS/2
>
>QUESTIONS:
>1) Why is 140k out of 640k unavailable to DOS with even a minimal
>   CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed?
>   (RMSIZE is = 640 in CONFIG.SYS)


Because the kernal and most of the device drivers in OS/2 1.x had to load
low.  This was to support the DOS box.  Some of the device drivers are
dual mode (i.e.  they are user by both the DOS compatibility coffin and
the OS/2 sessions themselves).

And no, there ain't no way to change it.  Guess you're SOL.


>2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable
>   to DOS (and not use its memory) (I only need telnet from OS/2)?

Nope

>3) Are there any TCP-IP packages (commercial or not) that either take a
>   small chunk of DOS memory or none at all?

I'll defer this and the next to the rest of the net......

>4) Are there utilities that will show me which drivers are using how much
>   memory?
>
>Please help me...I'm in a maze of twisty passages all alike!!
>
>--alen
>Please email to
>	alen@crash.cts.com
>I'll summarize for the net.
>
>


-- 
============================================================================
Eric Germann                "You see things; and you say 'Why'  But I dream
The Germann Associates       things that never were; and I say 'Why not?'"
eric@tga.com                -- "Back to Methuselah"  G.B. Shaw 1921 
Newsgroups: comp.protocols.tcp-ip
From: cfor@ciba-geigy.ch (Rainer Foeppl)
Subject: Telnet VT100/VT200 for TCP/IP on MVS (IBM large Systems)
Organization: Ciba-Geigy Ltd., Basel, Switzerland
Date: Tue, 26 Jan 1993 08:20:27 GMT


Hello
We have TCP/IP on MVS installed on our IBM Mainframes. IBM supports for Telnet
only linemode or their own 3270 Datastream.
But there is an independent vendor who sells the telnet interface for VT100 and
VT200 type terminals.

Is anybody out there aware of such a software-product and can give me the
address / phone # from the vendor ?

Thank you very much for your help
R. Foeppl
Ciba-Geigy AG
Address cfor@ciba-geigy.ch
Fax +41-61-675585

-- 
Rainer Foeppl
email: cfor@ciba-geigy.ch
Newsgroups: comp.protocols.tcp-ip
From: alen@crash.cts.com (Alen Shapiro)
Subject: IBM OS/2 TCP-IP uses DOS (low) memory? HELP ME PLEASE!!
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 23 Jan 93 16:43:58 GMT
Summary: I need telnet under OS/2 and need to run DOS progs larger than 360k?
Keywords: TCP-IP DOS OS/2 memory

I'm in a bind...

I have OS/2 v1.33 (can't use 2.0 due to lack of suitable device drivers)
I have an application that runs on a LAN (IBM Adaptor card) under OS/2
and talks with another application on DOS (can't put the DOS app. on
OS/2 due to lack of device drivers!!)

The OS/2 side needs to open a telnet session with a remote host. I have
IBMs TCP-IP (latest release = 2.1.1 (or thereabouts)).

The problem is that IBMs TCP-IP uses DOS memory for its 2 drivers IFNET
and INET. Each driver uses 100k and another 140k seems to be unavailable
to DOS (even with a fairly cut-down CONFIG.SYS). With 340k out of 640k
unavailable to DOS, I can't run my 360k DOS application.

QUESTIONS:
1) Why is 140k out of 640k unavailable to DOS with even a minimal
   CONFIG.SYS (i.e. no TCP-IP or LAN drivers)? ... Can this be changed?
   (RMSIZE is = 640 in CONFIG.SYS)
2) Can the TCP-IP drivers be persuaded to load high and thus be unavailable
   to DOS (and not use its memory) (I only need telnet from OS/2)?
3) Are there any TCP-IP packages (commercial or not) that either take a
   small chunk of DOS memory or none at all?
4) Are there utilities that will show me which drivers are using how much
   memory?

Please help me...I'm in a maze of twisty passages all alike!!

--alen
Please email to
	alen@crash.cts.com
I'll summarize for the net.
From: Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Moving from coax to 10BaseT
Date: Mon, 25 Jan 1993 20:29:50 -0800 (PST)
Organization: University of Washington
NNTP-Posting-Host: tomobiki-cho.cac.washington.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Just to add a side note to thinnet vs. 10BaseT argument.

I have a computer zoo in my residence.  The connectivity between the zoo
critters is thinnet, for two reasons:
 1) I'm too cheap to buy a hub
 2) one of the critters is a sweet old dinosaur who, when she gets the right
    connecting cable and a bit of programming, will think she is talking
    thicknet (albeit coerced to thinnet).

In spite of the limited scope of my thinnet, I have spent entirely too much
time debugging it.

If I were to do it again, I'd probably make it 10BaseT and figure some way to
coerce the dinosaur to play the 10BaseT game.

Newsgroups: comp.protocols.tcp-ip
From: cmaeda+@cs.cmu.edu (Christopher Maeda)
Subject: bug in ttcp: SO_RCVBUF, accept
Organization: School of Computer Science, Carnegie Mellon
Date: Thu, 21 Jan 1993 08:11:53 GMT


I noticed the following weird behavior using ttcp and the 4.3BSD TCP.
(Actually a Mach 3.0 system but the binaries and the TCP code are
4.3BSD Unix).

I wanted ttcp to advertise receive windows larger than 4k so I invoked
it as follows: 

	ttcp -r -s -b 32768 -l 16384

However, packet traces were showing that the receive windows were
always 4k.  For the arguments above, ttcp does the following syscalls:

	fd = socket(AF_INET,SOCK_STREAM,0);
	setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */
	listen(fd,...);
	fd = accept(fd,...)

In the TCP I'm using, the accept'ed connection doesn't pick up the
modified sockbuf parameters from the parent socket and therefore the
accept'ed connection has the 4k default receive window size.  If I
change the order of calls to the following, the accept'ed connection
advertises 32k receive windows.

	fd = socket(AF_INET,SOCK_STREAM,0);
	listen(fd,...);
	fd = accept(fd,...)
	setsockopt(fd,SOL_SOCKET,SO_RCVBUF,...); /* 32k rcv window */

So my question is this.  Is the second syscall sequence what ttcp
*should* have been doing or should the accept'ed socket have inherited
the sockbuf parameters from the parent socket (and therefore my TCP is
buggy).

-- 
Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
Newsgroups: comp.protocols.tcp-ip
From: duane@anasazi.com (Duane Morse)
Subject: EAGAIN error with poll() -- what resource is too small?
Organization: Anasazi, Inc.  Phoenix, Arizona USA
Date: Wed, 27 Jan 1993 01:10:41 GMT

The poll() system call may return -1 with errno set to EAGAIN.  I have
two questions regarding this condition.

First, is there a kernel resource which has run dry which can be
increased by some tuning parameter to prevent this?

Second, how should software handle this condition?  For instance, can
the software depend on getting a SIGPOLL signal later if poll was unable
to tell the software what to examine in the first place?
-- 

Duane Morse	e-mail: duane@anasazi.com
(602) 861-7609
Newsgroups: comp.protocols.tcp-ip
From: MACE@HDQCMS2H.UTSD.ATT.COM
Subject: Re: Anyone know of a good LPR/LPD Server?
Organization: None
Date: Thu, 21 Jan 93 18:55:25 EST

In article <930121101208@cream.ftp.com>
jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
 
>In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>
>    We have 10 LaserJet printers which we would like to connect to a LPD
>    server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
>    ...
>    We have looked at the Lantronix equipment, but that does not really
>    offer LPD; since we have a diverse user community, we want to use the
>    LPR and LPRMON software that is provided with the TCP/IP implementations.
>
>A number of the DOS TCP/IP vendors offer LPD servers of varying
>capabilities (B&W, Sun, FTP Software at least).  Ours is sold as a
>separate product, and handles multiple simultaneous printers, spools
>while printing, allows you to define multiple virtual printers with
>different initializations on a single physical printer, etc. (the
>same spooler is bundled into our OS/2 product).  There is also a
>freeware LPD, which I think can be found on tacky.cs.olemiss.edu.
>
>James B. VanBokkelen            2 High St., North Andover, MA  01845
>FTP Software Inc.               voice: (508) 685-4000  fax: (508) 794-4488
>
 
I was looking for a standalone device, rather than a process running
on a set of PCs to drive the printers... Black-Box has indicated that they
expect to have one in around March... I was hoping that there was something
with a proven track record, instead of having to be on the bleeding edge...
Thanks!
--------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ
--------------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip
From: mike@gordian.com (Michael A. Thomas)
Subject: Large Windows and Delayed Acking
Organization: Gordian; Costa Mesa, CA
Date: Thu, 21 Jan 1993 23:36:55 GMT


  I have been playing around with a TCP implementation trying to get
the throughput up and discovered an interesting anomaly with large
windows. The setup I have is a program which is an infinite data
source sending to the discard port (port 9) on a remote machine over
ethernet. I am merely measuring the bandwidth and occassionally reporting
that to the user -- nothing complicated.
  What I have found is that with large windows (say 16kb) the sending
TCP stops sending at about 4k and waits for the receiving TCP to
send an ACK. The receiving TCP, however is using a defered acking
scheme which tries to delay sending ACK until a larger window is
consolidated into one packet. The metric it is using is 1/2 the
buffer size, and the delayed ack period is on the order of 100ms.
  I can understand why a sending TCP might be leary of sending *so*
much data without hearing an ack, but my question is what algorithm
is the sending TCP using to determine how much data it will send
before going into this quiesent state? Is there an appropriate
RFC which I should read which describes this situation? Is the
behavior of the sending TCP correct?

  (BTW, I noticed that the IBM/AIX which extends a 16k window 
   has the same problem with a Sun running 4.1.2, so the problem
   is not unique to the TCP I'm futzing with...)
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)
From: kate@wavefront.wti.com (Kathy Samec)
Newsgroups: comp.protocols.tcp-ip
Subject: Slip and SGI machines
Date: 21 Jan 93 23:38:57 GMT
Distribution: usa
Organization: Wavefront Technologies Inc, Santa Barbara, CA

I will have to set Slip up on a SGI Indigo soon and would like to know
what software will run in this environment. Will cslip work? Also, Who 
can I contact to get a slip connection to the internet in the NYC area?

thanks
-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
From: kent@humu.nosc.mil (Kent K. Kuriyama)
Subject: Multiple class 'C' addresses versus single class 'B'
Keywords: addresses
Organization: Naval Research and Development, Hawaii Laboratory
Date: Sat, 23 Jan 1993 00:25:17 GMT

I would like to get comments regarding the problems of using multiple
class 'C' addresses vice a single class 'B' addresses.  Obviously
this is an issue because the NIC is hesitant in granting the rapidly
diminishing number of class 'B' addresses.

We intend to have approximately 2000 IP addresses with typically 50
address per sub-net.  Using class 'C' address we are looking at 40 sub-
nets or approximately 10 'C' addresses.

Questions:

1)  What kind of management problems will we run into if we use class
'C' vice 'B'?  It seems to me that use of multiple class 'C' addresses
would not change the number of routers required - the number of sub-nets
dictates that.

2)  Someone mentioned that linking up a bunch of 'C' addresses will
require the use of some external gateway protocol (make sense - we need
to route between class 'C' networks) on our routers.  Is this a big
deal?  Is EGP a feature only available on expensive routers?

3)  Are there any advantages to getting a contiguous set of class 'c'
addresses (e.g. 192.101.190,191,192, . . . etc)?

4)  Would there be any problem in implementing a single domain name
DNS over multiple class 'C' addresses?

Thanks.

Kent Kuriyama
kent@nosc.mil
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Please tell a newbie the differences betw FSP and FTP and ...
Date: 27 Jan 93 06:02:03 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA
To: schuetz@fm11ap01.tu-graz.ac.at

In article <1k15dsINNl17@fstgds15.tu-graz.ac.at> you write:
>1.) What is FSP exactly? I know and have seen FTP already and been told
>    that FSP is kinda similar.

In 12 years on the Internet, I have never heard about a protocol called
FSP.

>2.) Our "tn.exe" (telnet) preferres to make fuss. Sometimes I can easily
>    connect to an FTP site, but at the same time TN would't want to 
>    connect. ("Host unrechable, destination unreachable"). Strange...
>    In general, TELNET seems not to want to connect as easily as FTP. 

The owls, they are not what they seem ...
It is very common these days for routers to set up packet filters
that differentiate between FTP and TELNET. Many sites do not allow ANY
incoming TELNET traffic. The hosts that are unreachable by TELNET but
can be reached by FTP, are they hosts that you have been explicitly
authorized to TELNET to ? Do you have (legal) accounts on them ?

>Any help is greatly appreciated, E-mail answers preferred 'coz I cant
>sift through all the news everyday.

In general it is considered to be extremely rude to be too busy to read
the replies to your own postings ... You may not have time to read all
the news every day, but you should set aside time to read the groups to
which you are posting ...
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
Newsgroups: comp.protocols.tcp-ip
From: powell@wraith.netops.gtefsd.com (Mike Powell "GTE FSD Net Mgr")
Subject: Re: Anyone know of a good LPR/LPD Server?
Organization: GTE Federal Systems (Telecom)
Date: Thu, 28 Jan 1993 21:47:27 GMT

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.
> 
>Does anyone have any suggestions?
Yes,
I am currently looking at three products:
Microplex M200/M201 default config 2 serial and 1 parallel
Axis AX-5 default config 1 serial 1 parallel
Lantronix EPS1 default config 1 serial and 1 parallel

Axis:
I currently have an evaluation unit from Axis. it does true LPD and
Novell print services. It does what it advertises.
508-777-7957 or info@axisinc.com

microplex:
They are next on the list for evaluation. It currently supports
LPD and Novell support has been announced.
604-875-1461, 800-665-7798 or sales@microplex.com

Lantronix:
"Support for Novell, TCP/IP, Ethertalk (Appletalk), LAT"
They are last on the list.
See other postings....
Phone: 714-367-0050 or 800-422-7022

Mike
--
Mike Powell PPASEL
"It's hard to find router bits for your cisco"
Disclaimer: I speak for myself. No direct relation to the DUAT folks.
internet: powell@wraith.netops.gtefsd.com  Usenet: uunet!wraith.netops.gtefsd.com!powell
Newsgroups: comp.protocols.tcp-ip
From: amolitor@moink.nmsu.edu (Andrew Molitor)
Subject: TCP congestion/Nagle's algorithm
Originator: amolitor@moink.nmsu.edu
Organization: Department of Mathematics
Date: Sat, 23 Jan 1993 11:35:44 GMT


	Darn it, I think I put my foot in my mouth. After poking
through rfc896 (in which Nagle introduces his algorithm for
solving the 'small packet' problem) and comparing with Karn's
NOS TCP implementation, I find myself confused.

	First, I misunderstood congestion windows. My apologies
to whoever it was I responded to a day or so ago, blithely
dismissing throughput problems as 'sounds like a small congestion
window.'

	Second, Nagle seems to be saying that a TCP should not
send new data while unack'd data is outstanding, while Karn's
code seems to not send new data while unack'd data is outstanding
*unless* there is a max segment sized chunk to go out.

	Karn's version seems right, since it allows proper
streaming, while Nagle's seems to reduce the sliding window
to a stop and wait arrangement. Is Karn's algorithm in Nagle's
remarks, disguised as a tacit assumption that one always sends
all the data one has, in multiple segments? He seems to be implying
that as soon as one gets an ack, one sends all the data one has
on hand. This is still not quite Karn's implementation, I think.

	Andrew
Newsgroups: comp.protocols.tcp-ip
From: evansmp@uhura.aston.ac.uk (Mark Evans)
Subject: Re: Sequence Numbers in TCP/IP
Organization: Aston University
X-Newsreader: TIN [version 1.1 PL241235]
Date: Fri, 22 Jan 1993 14:26:37 GMT

Andreas Fasbender (andreas@informatik.rwth-aachen.de) wrote:
: Can somebody answer a stupid question:
: 
: What is the reason for the difference in the lenght of the window-field
: (16)

The window is how much the other end is prepared to accept (65535 implies
infinite). (this is bigger than the maximum packet size on every network
I have ever seen)

: and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing
: and acknowledging could spare 4 byte in each packet.

Sequence measures how much has been sent.

Both of these are measured in octets (8 bit bytes), it is quite reasonable
to expect a TCP link to send more that 64K octets in one session.
: Hope this isn+t a faq.
: 
--

-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |
Xref: sparky comp.protocols.tcp-ip:6036 comp.protocols.nfs:3171
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LPR and Fortran flow control RFC 1179
Date: 26 Jan 93 07:22:51 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <1993Jan22.170024.2775@vax1.mankato.msus.edu>
   robin@vax1.mankato.msus.edu writes:
>For output we get a complete printout on the host... but the fortran flow
>control is NOT interpreted and the "1" "0" "+".. etc. are printed.

The file is printed as transmitted. How would the print server host know
that this file came from FORTRAN ?

You need the format the FORTRAN Format Control (not flow control, that
means something else entirely) in a filter on the sending side.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Compressed slip packet driver? 
Distribution: world
Date: Thu, 28 Jan 93 02:08:58 GMT
Organization: Crynwr Software

In article <1993Jan26.142944.5026@spcvxb.spc.edu> 4carroll_j@spcvxb.spc.edu writes:

       Can anyone tell me where I might find a compressed slip packet driver?

As far as I know, one doesn't exist and no one is working on one.  Of
course, writing such a program is exactly what my company does...

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
From: jrb@rigel.cs.pdx.edu (James Binkley)
Newsgroups: comp.protocols.tcp-ip
Subject: query about 2 subnets/1 segment and directed bcast
Date: 27 Jan 93 02:31:52 GMT
Article-I.D.: pdxgate.6765

Back to 2 subnets on 1 segment again:

Greetings,

I was wondering if anyone might have any insight
into the following situation that involves 2 subnets
on the same ethernet segment:

Given the following setup:

net 140.140.1.0 subnet mask 255.255.255.0
net 140.140.2.0 subnet mask 255.255.255.0

The local topology is something like this:

default router:
		aix box  1.100
		  |
	cisco ---------------- subnets 1 and 2 (same wire) -------
					 | zymurgy
					 1.240/2.240

We have an experimental server on zymurgy that is sending 
out a directed broadcast on net 2 as 140.140.2.255. 
Zymurgy has the capability to have 2 ip addresses
attached to a single enet device.
		140.140.1.240
		140.140.2.240
It is sending the directed bcast out to 2.255 as an
ethernet bcast.

So anyway we have the real net '1' and the experimental
subnet on top of it, '2'. 

For "no apparent reason" an aix box and an hp X terminal too 
(both on net 1 with 1 interface and 1 ip address on that
interface)
are picking up the directed broadcast and forwarding it
as a unicast packet to the "default" cisco router.
Why a broadcast on another ip subnet is forwarded
is beyond me. The aix box is forwarding the packet too (
ip ttl is decremented; netstat -s shows forwarding count
incremented ). (Of course, it also happens
to not be a router in the real sense of the word -
The cisco then forwards
the unicast back to zymurgy but it has been told
already (via static routes) to forward any
default net 2 subnet packets to zymurgy -- so that is the
correct move. Nothing but static routes -- no rip or
any kind of dynamic routing used here.
Any insights here?  Mine is: "Life with 2 subnets
in the presence of buggy tcp/ip implementations can be
interesting :->"

			Jim Binkley
			jrb@cs.pdx.edu
From: andreas@informatik.rwth-aachen.de (Andreas Fasbender)
Newsgroups: comp.protocols.tcp-ip
Subject: Sequence Numbers in TCP/IP
Followup-To: comp.protocols.tcp-ip
Date: 22 Jan 1993 12:24:13 GMT
Organization: Institute of Computer Science IV
Distribution: world
NNTP-Posting-Host: i2pc5.informatik.rwth-aachen.de

Can somebody answer a stupid question:

What is the reason for the difference in the lenght of the window-field
(16)
and the sequence-number-field (32 bit). Using 16-bit-numbers for sequencing
and acknowledging could spare 4 byte in each packet.
Hope this isnt a faq.

Thanks
Andreas


:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
:    Andreas Fasbender       Institute of Computer Science IV     :
:                            Aachen University of Technology      :
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
Newsgroups: comp.protocols.tcp-ip