Re: [Lksctp-developers] sending multiple streams (as opposed to messages) between peers

[Vlad Y. <vla...@hp...>]

Andrei Matei wrote:
> Thanks for your reply, Vlad. Apparently I didn't look at these calls
> close enough. But now one thing is not clear to me: how can reads from
> message A coming on stream SA be interleaved with reads from message B
> coming on stream SB? It seems to me that, once recvmsg() has returned an
> incomplete message (MSG_EOR not set), any subsequent call to recvmsg()
> will refer to the same message A/stream SA, until the whole message has
> been sent and received. And the same on the sendmsg() side. Am I
> correct? If so, how would I deal with long-running streams carrying just
> one big message?
> 

That's one of the issues with big messages.  The later spec introduced multiple
interleave options that allows for stream interleaving i.e 2 streams in partial
delivery.  Linux doesn't implement that.  Not sure if we would ever do so.

So, if you are dealing with really large messages, you are really dealing with
streams and TCP might be better.  The other issue with really large messages
is that sometimes you send calls will block or even fail entirely.  SCTP api
introducd SCTP_EOR for sending side.  That essentially let's the sending
application explicitly mark the end of record, and everything prior to that
is considered part of a single messages.  But if you use that, you can't switch
streams.

SCTP was not designed with very large messages in mind, since the initial design
was for sigtrans which averages 256 byte messages :>

So, anything that's a few mtus long is fine, but if want to do 65K writes
similar to TCP, do not expect SCTP to excel.

-vlad

> Thank you,
> 
> - Andrei