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.
Steve> o sendmsg() - MSG_EOR indicates that the data sent is the
Steve> last in a record. Data in a sendmsg() call must all be part
Steve> of one record. If the sendmsg() call returns before all
Steve> the data is sent, then the MSG_EOR is ignored so that the
Steve> rest of the record may be sent in a later sendmsg() call
Steve> when more buffer space is available.
o.k.
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?
Steve> There was an obvious problem, in that with write() you
Steve> can't specify any flags, so the implicit MSG_EOR was added
Steve> so that it could do something vagely sensible without
Steve> forcing people to use sendmsg() to terminate each
Steve> record. (POSIX doesn't actually say if write() should have
Steve> an implicit MSG_EOR or not, it stays slient on the matter)
Steve> As to what to do when the sockets don't support sending
Steve> fragments, I'd suggest that they ought to print out a
Steve> message (suitably rate limited) that the application is an
Steve> old one and should be updated if it does not set
Steve> MSG_EOR. This seems to be the usual approach that I've seen
Steve> elsewhere around the kernel. Its probably also a good idea
Steve> to update as many applications as possible before this
Steve> message is added though.
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?
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).
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
|