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

From: Randall Stewart <[email-masked]>
Date: Thu, 03 Oct 2002 19:12:15 -0500

Kavitha:

I think we now leave the "making something explcit in a draft"
and move in to implementation details for me to discuss
this.. I am copying sctp-impl and will respond
removing tsvwg...

I think it is best we move it there..

If there are no further objections next pass of the sockets
api will specify we must be sure to move the data..

I will answer you tommorrow A.M. and see if I
can't confuse you more :>

R

Kavitha Baratakke wrote:
> Randall Stewart wrote:
> 
>>Kavitha Baratakke wrote:
>>
>>>Brian,
>>>
>>>That was just one case where we do a partial read before a peeloff...
>>>Randy's example of where peel_off occurs after a partial read (partial
>>>delivery) and we need to move the rest of the data to the new socket
>>>buffer...
>>>
>>
>>Kavitha: I was NOT talking about the partial delivery api.. that is
>>different than when a user does a partial read...
>>
>>The partial delivery api is when the sctp stack itself sends up
>>only part of the message .. that is different than the socket buffer
>>holding the whole message and the app reading only a couple of bytes...
>>
>>
>>>... sure we could make it mandatory that peeloff occurs before any
>>>reads...although handling it otherwise is really not that complicated...
>>>
>>
> Randall, how is partial delivery api different from user doing a partial
> read as far as how we need to handle it goes. We still need to keep
> track of which assoc the partial message belongs to in either case
> right?
> 
> I'm confused ???
> 
> 
>>As long as you don't mind having sctp specifics in your sockets
>>layer... of course Kacheong feels it is part of the sockets layer
>>so then there is no problem :>
>>
>>>But the original source of this discussion was that if data is lying in
>>>the socket buffer for the assocation that is peeled off, we still have
>>>to move it to the new socket buffer after peeloff...
>>>
>>
>>correct.
>>
>>and I think that should be stated in the socket draft at minimum.
>>
>>R
>>
> 
> 
>>>>Is it not simple to just require that the peel_off occur
>>>>before any reads on the association being peeled off?
>>>
> 
>>>>--brian
>>>>
>>>>--
>>>>Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>>>>[email-masked]    ¦ world; the unreasonable one persists in  ¦
>>>>http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>>>>                       ¦ Therefore  all  progress  depends on the ¦
>>>>                       ¦ unreasonable man. -- George Bernard Shaw ¦
>>>
>>>
>>--
>>Randall R. Stewart
>>[email-masked] 815-342-5222 (cell phone)
> 
> 

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 04 Oct 2002 06:23:57 -0500

>> track of which assoc the partial message belongs to in either case
Ok let me try to confuse you more...

Conceptually there is a large difference between the partial delivery
API and a user only reading part of a message.

The PD-API MUST be implemented in SCTP ... this is where
I start to send up the socket buffer a incomplete message to
try to cut down on my resource utilization. I let my upper
layer read off the first part that as arrived.

A user only reading part of a message DOES NOT depend on SCTP
doing anything. I realize this is really splitting hairs.... but lets
take for example a SCTP implementation that DOES NOT EVER
do the PD-API... it always sends up complete messages (some may well
do this).

Now in our mythical implementation it may send up a 4k message... the
message is pushed up the socket buffer... the user reads 1 byte...

The result from the user perspective is much like the PD-API.. even though
the SCTP implementation does NOT support it and does not do it..

Thats why I say the issue as nothing to do with the SCTP PD-API.. maybe the
way the sockets layer API for partial delivery might work.. but not SCTP..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)