HI,

I think you guys are not getting me, what I am asking.

I just want to know that, 

1. Does all TCP segments are of equal size i.e. of MSS, until whatever
left in send buffer is less than the MSS?

2. Can we set the MSS size at application level, say using
setsockopt()?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rajat wrote:
> HI,
> 
> I think you guys are not getting me, what I am asking.
> 
> I just want to know that, 
> 
> 1. Does all TCP segments are of equal size i.e. of MSS, until whatever
> left in send buffer is less than the MSS?

No.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Sort of. An application can /influence/ the MSS through appropriate syscalls.


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBy8SYagVFX4UWr64RAsC2AJ9PgyVL83tLFU6TiYH3mE+3i320NwCfff1i
zYGSQo98u+OyvUcq2eHOX4M=
=zS0v
-----END PGP SIGNATURE-----

In comp.protocols.tcp-ip Rajat <myself_rajat@yahoo.com> wrote:
> HI,

> I think you guys are not getting me, what I am asking.

I thing you are asking the wrong thing.

How TCP packtes data is done to make transmission more efficient,
that application has no need to know. The application receives
a stream of bytes - thats it !

If you need more detailed conrtrol over wire format use UDP or any
other encapsulation.


-- 
Peter H�kanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.

In article <cqgl1s$2t26$1@nyheter.ipsec.se>,  <phn@icke-reklam.ipsec.nu> wrote:

:How TCP packtes data is done to make transmission more efficient,
:that application has no need to know. The application receives
:a stream of bytes - thats it !

Unless the application has done an I_SRDOPT ioctl to switch to
message-discard or message-nodiscard mode instead of byte stream mode.
-- 
What is "The Ultimate Meme"? Would it, like Monty Python's
"The World's Funniest Joke", lead to the deaths of everyone who
encountered it? Ideas *have* lead to the destruction of entire cultures.
   -- A Child's Garden Of Memes

In article <b49ef75a.0412232304.4b3cf1b1@posting.google.com>,
Rajat <myself_rajat@yahoo.com> wrote:

:I think you guys are not getting me, what I am asking.

:I just want to know that, 

:1. Does all TCP segments are of equal size i.e. of MSS, until whatever
:left in send buffer is less than the MSS?

I explicitly answered that question already, with quotations from
the appropriate man page. Repeating myself:

    Under most circumstances, TCP sends data when it is presented; when
    outstanding data has not yet been acknowledged, it gathers small
    amounts of output to be sent in a single packet once an
    acknowledgement is received.

"sends data when it is presented" means "sends the data when
the write() system call makes the data available to the TCP layer".
If you only write() a few hundred bytes, then that's the size of packet
that will be sent, if there are no outstanding ACKs or if you have
used setsockopt() to set TCP_NODELAY.

Refer back to my posting for further quotations from man pages
that talk explicitly about there being internal minimum and maximum 
byte counts, and that if the write() size falls in between the limits
then the data will be sent immediately [except as modified by
the Nagle algorithm.] The usual cause, automatic fragmentation,
corresponds to the case of the lower limit being 0 that is discussed
in that man page section.


:2. Can we set the MSS size at application level, say using
:setsockopt()?

I answered that already too. Re-read the man pages I quoted
where it talks about pushing on a new top-level module. It is
in the same section that talks about the minimum and maximum byte
counts. Mentally invert the sens of what was written there:
where it says that the unless the application pushes a top-level
module that the application has no control over the limit values,
it is saying that if you *do* push a new top level module then
you have control over the limits.

Your previous posting didn't ask if you could "set" the MSS size,
it asked if you could *increase* the MSS. My response then discussed
why increasing the MSS is not usually a good idea.

If for some strange reason you needed to be able to change the MSS
size dynamically and you didn't want to go to the bother of
doing your own buffering and doing appropriately sized write()'s
that fell below the interface maximum MSS, then you could go the
streams module route and send a streams message to the appropriate
layer to change the MSS.
-- 
Can a statement be self-referential without knowing it?

Rajat wrote:
> HI,
>
> I think you guys are not getting me, what I am asking.

What we don't get is _why_ you are asking.  We get _what_ you are
asking but you don't like the answers or have failed tyo understand
them.

> I just want to know that,
>
> 1. Does all TCP segments are of equal size i.e. of MSS, until
whatever
> left in send buffer is less than the MSS?

NO, NO, and NO  How many times must we say this?  (excuse my shouting)

TCP segment size (negotiated for a _particular_ connection) will
_generally_ remain the same _unless_ you use PMTU or a monitoring
mechanism in FW/routing that resets MSS to clamp it.  There is NO --
get that, NO -- reason to increase it.  It is adjusted downward on
tranfers to prevent packet fragmentation which can occur at _any_ point
_between_ the connecting hosts -- a condition they have _no_ control
over except to adjust packet size _downward_ to _avoid_ fragmentation.
These adjustments are available on most platforms via a means similar
to Linux's ipsysctl mechanism.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

_Apps_ would not want to set this from code as it would require root
priviledges and there is _already_ a means to set these values to
configure the system.  Besides, the TCP/IP stack _already_ handles this
and _cannot_ be disabled.  Stop trying to break your networking stack.
If you insist on doing this, then read the source, Luke.

Look here for a quick review of TCP connection/data tranfer:
http://www.tcpipguide.com/free/t_TCPSlidingWindowDataTransferandAcknowledgementMech.htm

Check this RFC (among many others relevant to your questions):
http://www.faqs.org/rfcs/rfc1191.html
[quote]
3.1. TCP MSS Option
A host doing PMTU Discovery must obey the rule that it not send IP
datagrams larger than 576 octets unless it has permission from the
receiver.  For TCP connections, this means that a host must not send
datagrams larger than 40 octets plus the Maximum Segment Size (MSS)
sent by its peer.
[end quote]
Note: in fact PMTU does not work as reliably as it could because of
brain dead net admins and broken implementations -- thus the
"workaround" noted above re: packet framentation and clamping MSS.

Perhaps -- just a wild guess here -- if you told us _why_ you are
interested in doing this, someone could provide more appropriate
suggestions of how to go about it.

I'm done with this -- plan to enjoy my Christams.
hth,
prg
email above disabled

Rajat wrote:
> HI,
>
> I think you guys are not getting me, what I am asking.
>
> I just want to know that,
>
> 1. Does all TCP segments are of equal size i.e. of MSS, until
whatever
> left in send buffer is less than the MSS?
>
> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Excuse my self-followup -- left this out of last post:

http://www.faqs.org/rfcs/rfc879.html
RFC 879 - TCP maximum segment size and related topics
Cheers,
prg
email above disabled

In comp.os.linux.networking Rajat <myself_rajat@yahoo.com> wrote:
> I think you guys are not getting me, what I am asking.

> I just want to know that, 

> 1. Does all TCP segments are of equal size i.e. of MSS, until
> whatever left in send buffer is less than the MSS?

No.  There may be several send()'s worth of data in the send buffer,
and the TCP may or may not slice and dice from those sends to produce
full-MSSed segments.  You may often see long streams of MSS segments,
but you cannot ass-u-me it will always be that way.

Now, if it is a single send() it is _generally_ the case that all but
the last segment will be MSS - again though you cannot always ass-u-me
that - a short segment could in theory be generated by lack of remote
receive window, or perhaps even by the way the congestion window is
calculated.

So, you cannot always ass-u-me that a sort segment appearing after a
series of MSS segments means that was the end of a send().

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Depends on the stack.  Some allow it, some do not.

rick jones
-- 
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

"Rajat" <myself_rajat@yahoo.com> wrote in message 
news:b49ef75a.0412232304.4b3cf1b1@posting.google.com...

> I think you guys are not getting me, what I am asking.

    Why do you care? You are probably on the wrong track entirely.

> 1. Does all TCP segments are of equal size i.e. of MSS, until whatever
> left in send buffer is less than the MSS?

    If the number of bytes in the send buffer exceeds the MSS, there is no 
reason for a TCP stack to send a packet that contains fewer bytes than the 
MSS.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

    Not usually. Typically the buffer sizes have no relation to the segment 
sizes.

    Again, why do you care? Unless your writing or debugging a TCP stack, 
writing an invasive TCP packet proxy application, or writing a paper on TCP 
internals, you should *definitely* not care. If you're working in 
applications (which would be the only reason to ask about a socket option to 
change the MSS), there should be absolutely no possible reason you should 
care.

    DS

In comp.protocols.tcp-ip Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> In article <cqgl1s$2t26$1@nyheter.ipsec.se>,  <phn@icke-reklam.ipsec.nu> wrote:

> :How TCP packtes data is done to make transmission more efficient,
> :that application has no need to know. The application receives
> :a stream of bytes - thats it !

> Unless the application has done an I_SRDOPT ioctl to switch to
> message-discard or message-nodiscard mode instead of byte stream mode.

Never heard of it.  Probable very portable :-)


-- 
Peter H�kanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.

phn@icke-reklam.ipsec.nu writes:

>In comp.protocols.tcp-ip Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
>> In article <cqgl1s$2t26$1@nyheter.ipsec.se>,  <phn@icke-reklam.ipsec.nu> wrote:

>> :How TCP packtes data is done to make transmission more efficient,
>> :that application has no need to know. The application receives
>> :a stream of bytes - thats it !

>> Unless the application has done an I_SRDOPT ioctl to switch to
>> message-discard or message-nodiscard mode instead of byte stream mode.

>Never heard of it.  Probable very portable :-)

It's a STREAMs option; but it's unlikely to have any interesting effect
on TCP connections; the sender will never notice the option was
requested and the local stack will receive MSS sized packets as
before.  When these are then delivered, random bits will go missing.
It will not magically cause message boundaries to be preserved.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

> Unless the application has done an I_SRDOPT ioctl to switch to
> message-discard or message-nodiscard mode instead of byte stream mode.

I_SRDOPT is an option for Streams and not for TCP. It works if a
transport protocol honours this option. TCP is certainly not one of it.

Emil 

-- 
Philosys Software GmbH         System Software      Phone: +49 89/321407-40
Edisonstrasse 6                    is our             Fax: +49 89/321407-12
85716 Unterschleissheim          Speciality         EMail: egn@philosys.de
Germany                                               WWW: www.philosys.de

"David Schwartz" <davids@webmaster.com> wrote:

> 
> "Rajat" <myself_rajat@yahoo.com> wrote in message 
> news:b49ef75a.0412232304.4b3cf1b1@posting.google.com...
> 
> > I think you guys are not getting me, what I am asking.
> 
>     Why do you care? You are probably on the wrong track entirely.

He should really specify what he wants to achieve.

> 
> > 1. Does all TCP segments are of equal size i.e. of MSS, until whatever
> > left in send buffer is less than the MSS?
> 
>     If the number of bytes in the send buffer exceeds the MSS, there is no 
> reason for a TCP stack to send a packet that contains fewer bytes than the 
> MSS.

But there is certainly no absolut requirement for the stack to really
send a full MSS worth of data. The protocol stack is free to decide how
much data it sends. So nobody can rely on that the protocol stack always
sends a full MSS packet. 

Emil

-- 
Philosys Software GmbH         System Software      Phone: +49 89/321407-40
Edisonstrasse 6                    is our             Fax: +49 89/321407-12
85716 Unterschleissheim          Speciality         EMail: egn@philosys.de
Germany                                               WWW: www.philosys.de

Emil Naepflein wrote:
> "David Schwartz" <davids@webmaster.com> wrote:
> 
> 
>>"Rajat" <myself_rajat@yahoo.com> wrote in message 
>>news:b49ef75a.0412232304.4b3cf1b1@posting.google.com...
>>
>>
>>>I think you guys are not getting me, what I am asking.
>>
>>    Why do you care? You are probably on the wrong track entirely.
> 
> 
> He should really specify what he wants to achieve.
> 
> 
>>>1. Does all TCP segments are of equal size i.e. of MSS, until whatever
>>>left in send buffer is less than the MSS?
>>
>>    If the number of bytes in the send buffer exceeds the MSS, there is no 
>>reason for a TCP stack to send a packet that contains fewer bytes than the 
>>MSS.
> 
> 
> But there is certainly no absolut requirement for the stack to really
> send a full MSS worth of data. The protocol stack is free to decide how
> much data it sends. So nobody can rely on that the protocol stack always
> sends a full MSS packet. 
> 

To complete: The protocol can even send a different size
of segment for the same data if a retransmission is required.

The applications should never make *any* assumptions of
the TCP segmentation, it is *just only* a byte stream.
If any record delimiters are required, they have to be
coded into the transferred stream.

-- 

Tauno Voipio
tauno voipio (at) iki fi

In article <f1sqs059q0v5hnnhccsraortbu9ki0s28o@4ax.com>,
Emil Naepflein  <Emil.Naepflein@philosys.de> wrote:
:roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

:> Unless the application has done an I_SRDOPT ioctl to switch to
:> message-discard or message-nodiscard mode instead of byte stream mode.

:I_SRDOPT is an option for Streams and not for TCP. It works if a
:transport protocol honours this option. TCP is certainly not one of it.

Emil, TCP can (and has been) implimented in terms of STREAMS.
The following are from the SGI IRIX man pages:

$ man socket
[...]
     The socket has the indicated type, which specifies the semantics of
     communication.  Currently implemented types are:

          SOCK_STREAM
          SOCK_DGRAM
          SOCK_RAW

     A SOCK_STREAM type provides sequenced, reliable, two-way connection based
     byte streams.  An out-of-band data transmission mechanism may be
     supported.  [...]

$ man tcp
SYNOPSIS
     #include <sys/socket.h>
     #include <netinet/in.h>

     s = socket(AF_INET, SOCK_STREAM, 0);

DESCRIPTION
     The TCP protocol provides reliable, flow-controlled, two-way transmission
     of data. It is a byte-stream protocol used to support the SOCK_STREAM
     abstraction.


{i.e., TCP is the only implimented SOCK_STREAM}

$ man setbuf
NAME
     setbuf, setvbuf, setbuffer, setlinebuf - assign buffering to a stream
     logical unit [...]
C SYNOPSIS
     #include <stdio.h>

     void setbuf (FILE *stream, char *buf);

     int setvbuf (FILE *stream, char *buf, int type, size_t size);

     int setbuffer (FILE *stream, char *buf, int size);

     int setlinebuf (FILE *stream);

{Notice the references to 'stream'}

$ man 2 read
{The distinguished operation modes are:
  file
  STREAMS
  pipe
  FIFO
  terminal
  slave pty
  master pty
  file on a DMAPI filesystem (i.e., offline storage)
In particular, there is no mention of 'socket' at all.}

$ man 2 write
[...]
     For STREAMS files [see intro(2)], the operation of write is determined by
     the values of the minimum and maximum nbyte range (``packet size'')
     accepted by the stream.  These values are contained in the topmost stream
     module.  Unless the user pushes the topmost module [see I_PUSH in
     streamio(7)], these values can not be set or tested from user level.  If
     nbyte falls within the packet size range, nbyte bytes are written.  If
     nbyte does not fall within the range and the minimum packet size value is
     zero, write breaks the buffer into maximum packet size segments prior to
     sending the data downstream (the last segment may be smaller than the
     maximum packet size).  If nbyte does not fall within the range and the
     minimum value is non-zero, write fails and sets errno to ERANGE.  Writing
     a zero-length buffer (nbyte is zero) to a STREAMS device sends a zero
     length message with zero returned.  However, writing a zero-length buffer
     to a pipe or FIFO sends no message and zero is returned.  The user
     program may issue the I_SWROPT ioctl(2) to enable zero-length messages to
     be sent across the pipe or FIFO [see streamio(7)].


There is no mention at all of sockets in the write(2) man page, but the
section on STREAMS describes fragmentation into packets. Would it not
be rather strange to describe in detail packet fragmentation for the
obscure STREAMS and yet not even mention sockets at all, let alone
describe their fragmentation rules, unless sockets are indeed a kind of
STREAM ?


Stevens' "Unix Network Programming" specifically discusses
streams in the section on the X/Open Transport Interface (XTI).
Before XTI was TLI, the Transort Layer Interface.

opengroup.org's man page on STREAMS does, though, make it clear
that STREAMS are optional, but does not say the same for sockets.
-- 
   Will you ask your master if he wants to join my court at Camelot?!

In article <cql0fs$6ib$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:

>:I_SRDOPT is an option for Streams and not for TCP. It works if a
>:transport protocol honours this option. TCP is certainly not one of it.
>
>Emil, TCP can (and has been) implimented in terms of STREAMS.

As far as I know and recall, there have been two major implementations
of TCP/IP in System V STREAMS.  The first was done by people at Lachman
(perhaps Steve Alexander?) for AT&T and was part of what wrecked AT&T's
suit against BSDI when it came out that AT&T had been shipping the
Regent's code without the Regent's copyright legends.  Judging from
my diffs with with the SVR4 source, it consisted of the BSD 4.3 TCP/IP
of various flavors jammed into STREAMS modules.  The second was the
from-scratch Mentat code that Sun shipped in a paniced reaction to
that legal stuff.


>The following are from the SGI IRIX man pages:

Please check the IRIX kernel source instead of trying to infer from
man pages, which themselves were related to BSD and SV man pages. 
I think you'll find that IRIX STREAMS TCP/IP was really a wart on top
of and beside good old 4.3 BSD SOCKETS TCP/IP, including Sam Leffler's
protocol switch, Van Jacobson's slow-start, ack-pacing, and
header-predicting, etc.

Well, there is (or was?) also the other, later STREAMS-related wart
underneath among the interfaces, ostensibly to support SAPs.  What was
that over elaborate, committee designed, utter disaster of a driver
abstraction called?  I though it stupid because it required upper
layers to do things like handle the differing bit orders of IEEE MAC
addresses for 802.3 vs. FDDI.

(Survey the $author$ tags in RCS logs of the IRIX kernel TCP/IP and
STREAMS code to see the basis of those claims.)


>     For STREAMS files [see intro(2)], the operation of write is determined by
>     the values of the minimum and maximum nbyte range (``packet size'')
> ...

That seems to be confusing the SRV3 STREAMS in IRIX with the BSD
SOCK_STREAMS also in IRIX--at least as of IRIX 6.?.

>There is no mention at all of sockets in the write(2) man page, but the
>section on STREAMS describes fragmentation into packets. Would it not
>be rather strange to describe in detail packet fragmentation for the
>obscure STREAMS and yet not even mention sockets at all, let alone
>describe their fragmentation rules, unless sockets are indeed a kind of
>STREAM ?

Things are indeed strange, undreampt of things in heaven and earth.
20 years ago were already "streams," "STREAMS," "SOCK_STREAM," and
many other kinds of canals, rivers, creeks, pipes, aqueducts, and
other flowing things, all different and related.

As I see things, no one in their right minds writing a STREAMS module
for the TCP state machines would handle dividing data into segments much
differently than the BSD code does.  TCP is what it is.  If you are
building T/TCP, UDP, RDP, or something else, you might do other things.


I recognize the names of some contributors to this thread.  Greetings.
You guys are still far more gentle than I am.


Vernon Schryver    vjs@rhyolite.com

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

> Emil, TCP can (and has been) implimented in terms of STREAMS.
> The following are from the SGI IRIX man pages:

[snip]

I know that TCP/IP has been implemented with Streams because I am doing
development and support for one implementation since mor than 15 years.
But this doesn't mean that all kind of Streams functionality is
supported by TCP. 

> There is no mention at all of sockets in the write(2) man page, but the
> section on STREAMS describes fragmentation into packets. Would it not
> be rather strange to describe in detail packet fragmentation for the
> obscure STREAMS and yet not even mention sockets at all, let alone
> describe their fragmentation rules, unless sockets are indeed a kind of
> STREAM ?

Streams is a general framework for implementing network protocols. As
such it has to provide the interface to support all kind of
functionality. But, it doesn't mean that a specific implementation of a
protocol with Streams supports all the functionality.

> Stevens' "Unix Network Programming" specifically discusses
> streams in the section on the X/Open Transport Interface (XTI).
> Before XTI was TLI, the Transort Layer Interface.

The Tranport Layer Interface or now XTI is the equivalent to the socket
interface. Here the same is true as with the socket interface:
Not all calls and options work for a specific transport protocol
implementation. 

> opengroup.org's man page on STREAMS does, though, make it clear
> that STREAMS are optional, but does not say the same for sockets.

Streams is only a framework provided originally in UNIX System V Release
3.0 to implement all kind of protocols and protocol stacks. It does have
this high functionality at the system call interface because it is not
only used for implementation of network protocols. Originally the most
common use was for terminal line (tty) processing. Later it has been
used by Lachman to implement a streams-based internet protocol stack. 

Cheers,
Emil

-- 
Philosys Software GmbH         System Software      Phone: +49 89/321407-40
Edisonstrasse 6                    is our             Fax: +49 89/321407-12
85716 Unterschleissheim          Speciality         EMail: egn@philosys.de
Germany                                               WWW: www.philosys.de

Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote:

> To complete: The protocol can even send a different size
> of segment for the same data if a retransmission is required.

That's standard today if a less than MSS sized segment was lost and in
the meantime additional data has been placed in the output queue.

As I recall very early implementations like 4.1BSD retransmitted always
the same frame because the retransmission queue was frame-based and not
stream-based as in current implementations.

> The applications should never make *any* assumptions of
> the TCP segmentation, it is *just only* a byte stream.
> If any record delimiters are required, they have to be
> coded into the transferred stream.

Correct!

Cheers,
Emil

-- 
Philosys Software GmbH         System Software      Phone: +49 89/321407-40
Edisonstrasse 6                    is our             Fax: +49 89/321407-12
85716 Unterschleissheim          Speciality         EMail: egn@philosys.de
Germany                                               WWW: www.philosys.de

In article <cqlltg$15l$1@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
|In article <cql0fs$6ib$1@canopus.cc.umanitoba.ca>,
|Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:

|Please check the IRIX kernel source instead of trying to infer from
|man pages, which themselves were related to BSD and SV man pages. 

I would if I had access to the IRIX kernel source ;-)

Last I heard, SGI still charges very handsomely for access to the
source. Way *way* more than my organization could afford.  It probably
would have been less expensive for SGI to have just gone ahead and
given me access to the source than to have me pester the developers
with obscurities, but organizations don't think that way.  [I wouldn't
have had to pester you about the disappearing packets in IRIX 6.2 ;-) ]
-- 
'ignorandus (Latin): "deserving not to be known"'
   -- Journal of Self-Referentialism

In comp.protocols.tcp-ip Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> In article <f1sqs059q0v5hnnhccsraortbu9ki0s28o@4ax.com>,
> Emil Naepflein  <Emil.Naepflein@philosys.de> wrote:
> :roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

> :> Unless the application has done an I_SRDOPT ioctl to switch to
> :> message-discard or message-nodiscard mode instead of byte stream mode.

> :I_SRDOPT is an option for Streams and not for TCP. It works if a
> :transport protocol honours this option. TCP is certainly not one of it.

> Emil, TCP can (and has been) implimented in terms of STREAMS.
> The following are from the SGI IRIX man pages:

Again, writing something that needs a vendors specific "feature" is not
the way to create any portable code.

-- 
Peter H�kanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.