Re: recv() clarification in SCTP sockets API draft

[Michael Tuexen <[e-mail]>]

On Aug 5, 2010, at 9:03 PM, Brian F. G. Bidulock wrote:

> Michael,
> 
> Michael Tuexen wrote:                                                                                                                                      (Thu, 05 Aug 2010 11:24:05)
>> On Aug 5, 2010, at 8:56 AM, Brian F. G. Bidulock wrote:
>> 
>>> Randy, Michael,
>>> 
>>> Was it your intention to deviate from the POSIX behaviour
>>> of recv()?
>> The problem is that POSIX makes SOCK_SEQPACKET unreliable in
>> contrast to SOCK_STREAM. Having the same function (recv())
>> for the same protocol behave that differently, seems to be
>> wrong to me.
> 
> What do you mean?  POSIX says:
> 
> "SOCK_SEQPACKET
>       Provides sequenced, reliable, bidirectional,
>       connection-mode transmission paths for records.  A record
>       can be sent using one or more output operations and
>       received using one or more input operations, but a single
>       operation never transfers part of more than one record.
>       Record boundaries are visible to the received via the
>       MSG_EOR flag."
> 
> SOCK_SEQPACKET is clearly "reliable".  What do you mean by
How can I receive "using one or more input operations". I can't
do that with recv(), recvfrom() or recvmsg(). They drop the
bytes of the record which do not fit into the buffer. This
makes it "unreliable". As a receiver I have no idea how big
the largest message would be. For SCTP we do no want to loose
parts of the messages.

Best regards
Michael
> 
>> The problem is that POSIX makes SOCK_SEQPACKET unreliable in
>> contrast to SOCK_STREAM.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [e-mail]
> http://www.openss7.org/
>