Subject: Re:[Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about

From: venkat venkatsubra <[email-masked]>
Date: Wed, 02 Oct 2002 12:17:18 -0500

We don't have this bug in AIX. We move the
data as well as any pending notifications
(the peer could have sent some data and closed
the connection) to the peeled off socket. It is MP
safe too when new data (or any other chunk type)
comes to this association while the peeloff related
work is going on.

Venkat

> Message: 2
> Date: Wed, 02 Oct 2002 09:10:56 -0500
> From: Randall Stewart <[email-masked]>
> To: TSV WG list <[email-masked]>
> Subject: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about
>
> Hi all:
>
> I just had an interesting thought..
>
> When I do a
>
> sctp_peeloff(...)
>
> what happens to data that has not been read for the association being
> peeled off?
>
> In most implementations you stuff the data up a socket buffer... with
> no way to reach up and grub the data out of the socket buffer.. not
> that you would want to do this anyway since this is an EXTREME layer
> violation and leads to spagetti code.....
>
> If I do nothing and data is pending on the socket for the
> association being pulled off I have an issue that I may deliver data
> out of order... depending on which socket is read first of course...
>
> R
>
> --
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>
> --__--__--
>
> Message: 3
> Date: Wed, 02 Oct 2002 10:38:31 -0500
> From: Jon Grimm <[email-masked]>
> Organization: IBM
> To: Randall Stewart <[email-masked]>
> CC: TSV WG list <[email-masked]>
> Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about
>
> Randall Stewart wrote:
> > Hi all:
> >
> > I just had an interesting thought..
> >
> > When I do a
> >
> > sctp_peeloff(...)
> >
> > what happens to data that has not been read for the association being
> > peeled off?
> >
> > In most implementations you stuff the data up a socket buffer... with
> > no way to reach up and grub the data out of the socket buffer.. not
> > that you would want to do this anyway since this is an EXTREME layer
> > violation and leads to spagetti code.....
> >
>
> > If I do nothing and data is pending on the socket for the
> > association being pulled off I have an issue that I may deliver data
> > out of order... depending on which socket is read first of course...
> >
>
> Yes.  This is a problem.  LKSCTP currently has this feature/bug too,
> but we can fix it by grubbing through the socket read queue (the socket
> buffer is  really just a list of buffers) under locking.
>
> Our notifications also sit in the socket read queue too, so those
> too may need moved to the peeled off socket.
>
> BTW, we must use the socket's read queue to make poll/select work.
>
> We'll have to take a quite painful lock, but the alternative
> as described above is not very acceptable to the application.
>
> Just to put in an implementor's 2 cents,
> Jon
>
> >
> > R
> >
> >

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 02 Oct 2002 12:33:49 -0500

venkat venkatsubra wrote:
> We don't have this bug in AIX. 

It is not really a bug but an unspecified behaviour that
needs to be put down ..(in the sockets api draft)

 >                                 We move the

A question for you then.. does your socket's implementation
have a single socket buffer for the upper layer to read
from?

If so, how do you move the data without doing a layer violation
and plunging through the data in the socket buffer (grubbing has
La Monte frased it :>)?

R

---

From: venkat venkatsubra <[email-masked]>
Date: Wed, 02 Oct 2002 16:54:05 -0500

Randall,

> needs to be put down ..(in the sockets api draft)

If a server application for example on
getting a new association notification
does a sctp_peeloff() and forks off a child
to handle the new association, and the child
process (which deals with only the peeled off socket)
is not guaranteed to get the data sent over that association ,
then it sounds like a bug to me.

> have a single socket buffer for the upper layer to read

Yes, we have a single socket.

> and plunging through the data in the socket buffer (grubbing has

We do go into the socket buffer to move the data,
notification, etc. to the new socket.  Also,  on a MP system
while this is going on,  a new packet could hit the original socket
when a pcb lookup is done. We take care of that case too by
directing it to the new socket after the peeloff work is completed.

Venkat

---

From: Randall Stewart <[email-masked]>
Date: Wed, 02 Oct 2002 19:45:25 -0500

> then it sounds like a bug to me.

You still miss my point .. the behavior is NOT specified and
needs fixing in the document..

> directing it to the new socket after the peeloff work is completed.

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..

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...

R