Subject: [Tsvwg] Re: tsvwg digest, Vol 1 #756 - 10 msgs

From: venkat venkatsubra <[email-masked]>
Date: Thu, 03 Oct 2002 17:43:42 -0500

Randall,

> --__--__--
>
> Message: 10
> Date: Wed, 02 Oct 2002 19:45:25 -0500
> From: Randall Stewart <[email-masked]>
> To: venkat venkatsubra <[email-masked]>
> CC: [email-masked], [email-masked]
> Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about
>
>
> So how do you tell which association goes with which data... do you
> keep back pointers and such? If you use a mbuf like structure do
> you have EVERY chained mbuf assured of having this information..

We attach a sctp_sndrcvinfo structure with each message
in the socket buffer. We made this a mbuf type of MT_CONTROL.
And the notification stuffs (SHUTDOWN, ASSOC_CHANGE, etc.)
we keep it as a MT_SONAME mbuf type.
So, getting the assoc_id and moving the messages or
notifications of a particular assoc_id is not an issue.
As Kacheong had pointed out you need it anyway
to pass to recvmsg.

> It is also possible to read 100 bytes (of a 1000 byte message) and then
> do the peel off... in the case of a BSD system this may well loose the
> M_PKTHDR (which is where any back pointers could possibly be kept) and
> thus you would have data left on the socket with no way to tell
> which association went with that data for the partially read message...

To support partial delivery api we insert the
"control" structure back again at the head
of the message after the user does a partial read.

>
>
> R
>
> >
> >>R
> >>
> >>--
> >>Randall R. Stewart
> >>[email-masked] 815-342-5222 (cell phone)

Venkat

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: venkat venkatsubra <[email-masked]>
Date: Thu, 03 Oct 2002 17:45:00 -0500