Subject: Question about socket API

From: "Rajib Sarkar" <[email-masked]>
Date: Fri, 7 Nov 2003 11:45:02 -0800

Hi,
	I am implementing the socket API draft and have a question about TCP (one
to one) style vs. UDP (one to many) style interfaces. After reading the
draft I understood that the draft recommends the user to use one to many for
all new application. Is there any reason for that? Some places the draft
says "it is more efficient in terms of using most new SCTP feature", can you
please provide some example?
	In the draft it is stated that if we use different buffers for each
association in one to many style socket, and before sending data if we use
select call to find out whether the socket is blocked, is there any way we
can find for which association the socket is blocked?
	Any help will be highly appreciated.
Thanks
Rajib

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 07 Nov 2003 15:24:53 -0800

> please provide some example?

Where do you read it in the draft saying that all new
applications are recommended to use 1-N socket?  If there is
such a line, we should probably remove it...

The "efficient..." sentence was left there since the early
days of the draft.  I guess it should probably be removed
too.  The same mechanism is used for both 1-1 and 1-N style
socket to exploit new SCTP features.  So I don't think one
is more efficient than the other in this aspect.

> can find for which association the socket is blocked?

The select() part in the current draft for 1-N style socket in
sending is close to broken.  For sending, a reasonable
semantics for select() on 1-N style socket is to return true
always.  Note that I am talking about semantics here, not
about the actual implementation which can lead to many different
behaviors.  The reason to return true is that the socket
is not really tied to any association it controls.  So it "may"
assume that one of them got to be writable.  But in general, I'd
suggest 1-N style socket not to be used with select().  The call
is not designed for it.

That part of the draft should be re-written in the next version.

To summarize, I guess which programming style to pick really
depends on the app.  For some app, using the 1-1 style socket
may be more efficient while for another app, 1-N style is better.

You asked about select() and people have claimed that it is
slow and can only work for a limited set of file descriptors.  I
believe the reason for the select() limit is some C standard for
32 bit apps.  For example in Solaris, the FD_SETSIZE limit of
select() for 64 bit apps is 64K.  I think this is also true for
other 64 bit OSes.  To go higher than that and be more efficient,
most OSes have other mechanisms, such as poll(), /dev/poll, ...
And most OSes also have asynchronous socket ops which provide
similar semantics as the 1-N style socket.  But until the async
socket becomes (it may have already) a standard, this kind of
mechanism may not be portable.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 07 Nov 2003 15:49:28 -0800

Rajib Sarkar wrote:

> 	See my comments below.
> 	In the receive path I have to do select, but in the sending path I am not
> sure why do I need to do a select(), is it always non blocking in the send
> path?

I think this was discussed before in the list, can't remember
for sure.  I believe it was suggested that the 1-N style socket
should be set to non-blocking at the start of a program.  Do not
call select() on sending for 1-N style socket.  Check the return
value of sendmsg() and errno instead, and see if the particular
association is writable.

-- 

						K. Poon.
						[email-masked]