headers
Randall Stewart | 1 Oct 2002 18:26
Picon
Picon

Some SCTP code of interest

Hi all:

Ok I finally found a few cycles to get the apache2/mozilla hacks
I put together where they could be downloaded.

If you go to

http://www.sctp.org

and have a FreeBSD4.6 system with our kame-sctp version enabled
(you can get it from http://www.kame.net)

You can download these two packages

apache2.tar.gz
and/or
mozilla.tar.gz

and then compile and build them... they are pre-configured for
FreeBSD 4.6 (and patched too).

Once you do this you will have a httpd server and a mozilla browser that
will ONLY do SCTP :-)

I do have an IP address I can give folks (ask me offline in a email)
that has a apache2 SCTP server running on it with a clone of the 
sctp.org web page... in case you want to check out http over SCTP on the 
Big I :->

Best regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Stewart | 2 Oct 2002 16:10
Picon
Picon

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
randall <at> stewart.chicago.il.us 815-342-5222 (cell phone)
Permalink | Reply | 3 comments |
headers
Jon Grimm | 2 Oct 2002 17:38
Picon
Favicon

Re: 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randall Stewart | 2 Oct 2002 18:00
Picon
Picon

Re: A SCTP sockets/sctp_peeloff() issue to think about

Jon Grimm wrote:
> 
> 
> 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
venkat venkatsubra | 2 Oct 2002 19:17
Picon
Favicon

Re:A SCTP sockets/sctp_peeloff() issue to think about

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 <randall <at> stewart.chicago.il.us>
> To: TSV WG list <tsvwg <at> ietf.org>
> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Randall Stewart | 2 Oct 2002 19:33
Picon
Picon

Re: A SCTP sockets/sctp_peeloff() issue to think about

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

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

--

-- 
Randall R. Stewart
randall <at> stewart.chicago.il.us 815-342-5222 (cell phone)
Permalink | Reply | 2 comments |
headers
Jon Grimm | 2 Oct 2002 21:15
Picon
Favicon

Re: A SCTP sockets/sctp_peeloff() issue to think about

Randall Stewart wrote:
> Jon Grimm wrote:
>> Randall Stewart wrote:

> 
> This is a very bad idea I think..a lower layer grubbing through a higher
> kernel layers data structure is ALWAYS a bad idea and leads to spagetti
> or worse.. badly broke when the upper layer (sockets in this case)
> changes something and just happens not to tell you or change
> the SCTP code.. after all this is its private domain...
> 

I'm already in the SCTP specific portions of code at this point, so
Its not too painful really... I have an assoc_id that I'm comparing
against.  I just have to hold off the lower layer for a bit
while we walk the list.

> Well one could always run a tracking queue to find out when
> things were read.. I know BSD allows you to get a notification
> when something is read ... it even tells you if it was the
> End of a Message... so one could
> 
> allocate a small ds that has two pointers... one
> to make a complete linked list of all elements..
> 
> have the head in the endpoint info
> 
> Then the other list head could be on the association. This would
> be the second pointer that would point to the next element to be read
> for this association...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kacheong Poon | 2 Oct 2002 21:35
Picon
Favicon

Re: A SCTP sockets/sctp_peeloff() issue to think about

Included message from Randall Stewart <randall <at> stewart.chicago.il.us>:

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

Why is it a layer violation?  The sctp_peeloff() call is in the
socket layer.  What the code should do is to move the data or
notification of the specified assoc id from the old socket to
the new socket.  There are some race conditions involved, such
as interaction between the SCTP layer and socket layer, but
should be doable.  And the SCTP layer does not need to know
(Continue reading)

Permalink | Reply | 4 comments |
headers
Randall Stewart | 2 Oct 2002 21:44
Picon
Picon

Re: A SCTP sockets/sctp_peeloff() issue to think about

Kacheong Poon wrote:
> Included message from Randall Stewart <randall <at> stewart.chicago.il.us>:
> 
> 
>>----
>>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...
>>----
> 
> 
> Why is it a layer violation?  The sctp_peeloff() call is in the
> socket layer.  What the code should do is to move the data or
> notification of the specified assoc id from the old socket to
(Continue reading)

Permalink | Reply | 3 comments |
headers
venkat venkatsubra | 2 Oct 2002 23:54
Picon
Favicon

Re: A SCTP sockets/sctp_peeloff() issue to think about

Randall,

Randall Stewart wrote:

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

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.

>  >                                 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.
> >
>
> A question for you then.. does your socket's implementation
> have a single socket buffer for the upper layer to read
> from?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane