Subject: Re: [Tsvwg] SCTP stream information

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 18 Jan 2007 20:27:57 +0000

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 12:37 PM
> To: 'Michael Tuexen'
> Cc: 'TSWG', 'Preethi Natarajan'
> Subject: Re: [Tsvwg] SCTP stream information
> 
> 
> Hmm... that works only for the next message
> after the one you are currently reading.
> 
> Thats great once you get past the first sctp_recvmsg() with
> the SCTP_EXTRCV option set...
> 
> Brian points out an expensive alternative.. i.e. read 1 byte
> with MSG_PEEK.
> 
> Seems to me we could probably do a socket option pretty easily
> that would return the next sinfo to be read..
> 
> Something like
> 
> getsockopt(sd, IPPROT_SCTP, SCTP_NEXT_SINFO, &sinfo, &sinfo_len);
> 
> It should be pretty easy to implement.. but is it really something
> we want to do to get beyond the first message problem (instead
> of a MSG_PEEK)...
> 

I'm assuming that the purpose is to peek ahead so that the stream
can be identified and a buffer appropriate for that stream can be
used to receive the message.

Peeking is a rather clumbsy method to achieve that goal. It would
be far more natural to simply have an asynchronous post of a stream
specific buffer, and then a method of getting the next completed
message. That completion would identify what buffer had been used.