[Top] [All Lists]

Re: MSG_EOR flag

To: eis@xxxxxxxxxxxxx (Henner Eisen)
Subject: Re: MSG_EOR flag
From: Steve Whitehouse <steve@xxxxxxxxxxxxxx>
Date: Thu, 2 Mar 2000 21:21:41 +0000 (GMT)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200003021934.UAA13661@xxxxxxxxxxxxx> from "Henner Eisen" at Mar 02, 2000 08:34:46 PM
Organization: ChyGywn Limited
Reply-to: Steve Whitehouse <Steve@xxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

> Hi,
> >>>>> "Steve" == Steve Whitehouse <steve@xxxxxxxxxxxxxx> writes:
>     Steve> Hi,
>     Steve> The flag is part of the draft POSIX standard, which I
>     Steve> followed when updating the code. Basically it works like
>     Steve> this...
> Is this described in the documents available on the net? Last time
> when I checked (probaly too long ago), socket stuff not important for
> AF_INET was not really covered by the documents. 
So far as I'm aware there is nothing available on the net, unfortunately.

[some deleted text]
>     Steve>  o recvmsg() - Each call may only return data from a single
>     Steve> record. MSG_EOR is returned when the last bit of data from
>     Steve> a record is returned.
> Now I'm a little confused. Does POSIX always allow to return partial
> packets (some fragments only), just the recvmsg() containing the last
> fragment needs to set MSG_EOR? Or does POSIX even require that each
> segment is passed seperatly?
You can return partial packets, but each call to recvmsg() must only
return part (or whole) of one record. It must never return parts of
more than one record in a single call. MSG_EOR is only set by recvmsg()
on the final part of a record.

You can just set MSG_EOR (as you suggest below) on each recvmsg()
call if each call always results in a whole record being copied to
the user.
This is very unlikely to result in correct behaviour though... you've
no idea (from the kernel side) how big a buffer a user is going to
give you to put the data in. Unlike SOCK_DGRAM you must not discard
records with don't fit in the buffer, but must keep the part not yet
sent to the user so the user can request it later.

POSIX says that SOCK_SEQPACKET is basically identical to SOCK_STREAM
except for the MSG_EOR makers which just act like tags at certain points
in the data stream. Everytime you come across a MSG_EOR marker it
marks the end of a recvmsg() or sendmsg() call.

If you are looking for the "quick fix" for 2.2.xx though I'd certainly
support your suggestion of always returning MSG_EOR from recvmsg()
over the current behaviour. So long as the applications always have
a large enough buffer size, which from your comments I gather they do,
then everything should work fine.

[more deleted text]
> Should older kernels (2.2.x) also be modified to at least accept MSG_EOR
> such that the re-comopiled application (which set MSG_EOR properly) will
> continue to work with 2.2.x?
Hmm. Good question. Its not a bad idea to do that I guess. Probably the
person to ask is Alan Cox since he looks after the 2.2.xx kernels now.

>     Steve> btw, are you thinking about AX.25 ? So far as I'm aware its
>     Steve> the only other SEQPACKET supporting protocol...
> I was thinking about X.25, where write() broke from the implicit MSG_EOR.
> I did fix that soon, and also made MSG_EOR mandatory because the current
> X.25 does not support sending incomplete packets. From your rationale above
> (thanks!), this seems to be the correct behavior. Now, I understand, that
> I also need to always set MSG_EOR in recvmsg (because the current PF_X25
> does never return partial packets).
Yes, but see my earlier comments.

> The further question is what to do with 2.2.15. As PF_X25 is marked
> CONFIG_EXPERIMENTAL, people are expected to deal with occasional API
> changes (I don't think that there are applications using send/secvmsg
> anyway). As people will continue to use 2.2.x for some time, I think
> it is appropriate to set MSG_EOR on recvmsg() and accept (but not enforce)
> MSG_EOR on sendmsg() for 2.2.x, too.
> Or should I better leave it in 2.2.x as it currently is?
> Henner

I think its probably a good idea to do the patch for 2.2.xx. Its
fairly easily done and I can't see it having any unwanted side effects,


<Prev in Thread] Current Thread [Next in Thread>