Subject: [[email-masked]: [Tsvwg] SCTP Sockets API Question]

From: Chuck Winters <[email-masked]>
Date: Wed, 30 Oct 2002 07:24:14 -0500

It didn't look like tsvwg wanted to take this, so I figured I would 
forward it over here :)

Chuck
----- Forwarded message from Chuck Winters <[email-masked]> -----

Date: Tue, 29 Oct 2002 08:58:33 -0500
From: Chuck Winters <[email-masked]>
To: [email-masked]
Subject: [Tsvwg] SCTP Sockets API Question
User-Agent: Mutt/1.2.5i

Hello All,
	There are a few questions I would like to ask.  I noticed that there was
a major effort made to keep the UDP style and TCP style SCTP sockets 
compatible with current programs written to use UDP or TCP.  There also 
seems to be an unnecessary restriction on the UDP style SCTP socket.  Why
the error when calling accept on a UDP style socket?  I understand we want
TCP and UDP compatability, but this seems unnecessary.

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

----- End forwarded message -----

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 30 Oct 2002 07:32:06 -0600

Chuck:

Sorry I have been traveling or I would have answered there... still catching
up in email :>

A UDP style socket is more correctly called a 1 <-> Many type socket. I.e. a
socket represents multiple associations. Now calling listen() makes sense
to enable the server side (if you will) to get incoming associations... 
however
how would one in a 1 <-> Many socket use accept?

Accept is used to give you an new socket descriptor that holds the incoming
association... but that would be the same descriptor in the case of a UDP
style socket... Unless you wanted to take one of the associations into its
own socket.. but which one? You can't specify an address to accept() so this
is why sctppeeloff() was put into the spec..

Hope that helps..

R

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

---

From: Jon Grimm <[email-masked]>
Date: Wed, 30 Oct 2002 08:02:39 -0600

Hi Chuck, 

Chuck Winters wrote:

> compatible with current programs written to use UDP or TCP. 

Well, I'll at least agree on with you on TCP-style being a close
approximation to SOCK_STREAM/TCP semantics, but not so with UDP-style. 
Both are more programming models with an API on top of them to propogate
that model.  

At the last bakeoff we discussed some of the defaults that might make
UDP-style more SOCK_DGRAM like -> auto-accept (listen) ON, all events
OFF, auto-close ON.  However, this would likely not be the right thing
to do, as this would just further confuse folks into thinking that
UDP-style is attempting SOCK_DGRAM/UDP transparency.  

> TCP and UDP compatability, but this seems unnecessary.

I'd have to understand why you were interested.  If we could disable
auto-accept on listen() behavior, it seems possible to queue up the
associations and let them get accept()ed manually by the application,
instead of auto-accept.  So its probably possible to write, However..... 

....if you are porting a UDP application, you wouldn't do an 'accept()',
and if you aren't, you have other alternatives - such as peeloff and
events which are more powerful/flexible.  If you really _do_ want
'accept()' maybe TCP-style is better suited for your application??

Just some half-baked thoughts,
Jon Grimm

---

From: Chuck Winters <[email-masked]>
Date: Thu, 31 Oct 2002 08:21:45 -0500

Randall,

> how would one in a 1 <-> Many socket use accept?
What type of application would use this interface?
> is why sctppeeloff() was put into the spec..
What about accept() have semantics something like sctppeeloff where accept() 
returns the first association in it's list?

Chuck

-- 
Chuck Winters                            | Email:  [email-masked]
Distributed Processing Laboratory        | Phone:  856-338-3987
Lockheed Martin Advanced Technology Labs |
1 Federal St - A&E-3W                    |
Camden, NJ 08102                         |

---

From: Chuck Winters <[email-masked]>
Date: Thu, 31 Oct 2002 08:26:00 -0500

Jon,

> Both are more programming models with an API on top of them to propogate
Could you clarify a little what the programming model of the UDP-style is?
> 'accept()' maybe TCP-style is better suited for your application??
I'm not really looking for UDP transparency, I'm looking more at a connected
datagram type of service for new applications.
Thanks,
Chuck

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 31 Oct 2002 08:55:25 -0600

Chuck:

Ok... I think the basic question you are asking is what/why would you 
use the UDP model/style

Now from my view here is what the UDP or 1 to N style gets you:

1) Automatic acceptance of associations (you still have to specify a 
listen() call.. even though
    in the socketapi authors group I fought against this .. you don't 
always get what you want )
2) The ability to auto close idle associations
3) Only one socket descriptor to manage/worry about

Basically the idea is to have a single socket that gets all associations 
and just
gets data from various endpoints.. much like a open UDP socket. I, the 
application
programmer, no longer must worry about accepting connections and 
tracking file
descriptors... instead it looks akin to UDP where I just get data from 
various peers
and when I send to a peer it just goes there...

This also allows bundling of data on the cookie-echo message (3rd leg of 
the 4-way
handshake in SCTP)... the tcp style can not do this due to the vaguries 
of the socket
api interface.

In all of my servers using the UDP style I would:

1) turn autoclose on.
2) do a single listen()
3) receive messages and respond to them

Nothing else is required...

R