Subject: Re: [Tsvwg] Socket API draft

From: Randall Stewart <[email-masked]>
Date: Sun, 01 Apr 2007 08:09:06 -0400

Sirigiri, Anil Kumar Reddy (STSD) wrote:
> Hi,
> 
> Can someone please clarify my following doubts about socket API draft:
> 
> 1/ Should there be a bind() prior to sctp_bindx() ? -- I see it
> mentioned in one of tsvwg's mails, in the past, but couldn't find an
> answer.

In theory you should be able to use sctp_bindx instead of bind().

> 
> 2/ What is the use of sctp_opt_info() to have assoc_id as the parameter
> ? I see that all sctp_opt_info() options are having the assoc_id in the
> option argument structures. Though, there is no harm in having it, I
> just have this question out of curiosity to know the reason behind it.

sctp_opt_info() was created for O/S's that cannot pass information
in on a getsockopt() call. You want to pass info in when you are
explicitly getting information on an association. In BSD land
either sctp_opt_info or getsockopt() will work.. in fact sctp_opt_info
just calls a getsockopt()... since BSD allows the passing of
information in to the getsockopt call.

Other o/s's .. for example solaris .. use a streams based stack
which is pretty strict on not allowing data coming in to a
getsockopt call.. at least thats what I have been told.

Hope that helps..

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 1 Apr 2007 07:11:19 -0600

Randall,

Randall Stewart wrote:                        (Sun, 01 Apr 2007 08:09:06)
> getsockopt call.. at least thats what I have been told.

STREAMS XTI/TPI supports both getsockopt() and setsockopt() through
a single options management request interface.  Information is both
transferred in and transferred out in the same call.  So, not only
can options mangement pass information with a get operation, it can
retrieve information with a set operation.

 http://www.openss7.org/man2html?3+t_optmgmt
 http://www.openss7.org/man2html?7+T_OPTMGMT_REQ
 http://www.openss7.org/man2html?7+T_OPTMGMT_ACK

Any limitation is certainly not the fault of the TPI interface.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Sirigiri, Anil Kumar Reddy (STSD)" <[email-masked]>
Date: Tue, 3 Apr 2007 10:04:31 -0000

: > 2/ What is the use of sctp_opt_info() to have assoc_id as the 
: > parameter ? I see that all sctp_opt_info() options are having the 
: > assoc_id in the option argument structures. Though, there 
: is no harm 
: > in having it, I just have this question out of curiosity to 
: know the reason behind it.
: 
: sctp_opt_info() was created for O/S's that cannot pass 
: information in on a getsockopt() call. You want to pass info 
: in when you are explicitly getting information on an 
: association. In BSD land either sctp_opt_info or getsockopt() 
: will work.. in fact sctp_opt_info just calls a 
: getsockopt()... since BSD allows the passing of information 
: in to the getsockopt call.

Thanks for clarifying this. Yes, I got this point from the draft -- I do
not have any questions on the 'need' of it. My question is related to
the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
my previous mail. Considering the following API syntax:

	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
socklen_t *size);

Here, why do we have 'id' (association id) as the parameter when we
already have this as a member in all opt's "arg" structures applicable
to sctp_opt_info() ? 

--
Anil

---

From: Randall Stewart <[email-masked]>
Date: Tue, 03 Apr 2007 08:18:32 -0400

> already have this as a member in all opt's "arg" structures applicable
I believe it would probably be for the same reason that
Kacheong sites that we have the call in the first place...

Kacheong? Is that why :-D?

R

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 04 Apr 2007 18:45:05 +0800

> already have this as a member in all opt's "arg" structures applicable

My vague memory suggested that that this may an historical
artifact in the merge of 1-1 and 1-N style SCTP socket.  In
the pre-00 version of the draft, I believe there was no
association ID in those socket option structures.  So there
was a need for the ID in the sctp_opt_info().  Then the same
structures were modified to have the association ID.  Since
it is better for both getsockopt() and sctp_opt_info() to use
the same structures and we didn't want to change the function
prototype, it was kept.  Note that this was just from memory...

BTW, in the 00 version of the draft, the text for sctp_opt_info()
was written as

  getsockopt() is read-only, so a new interface is required when
  information must be passed both in to and out of the SCTP stack.

The first part is the reason for the function.  We want to keep
the getsockopt() semantics to be read-only, as applied to all
other types of sockets.  The option value argument will be not
be copyin.  It is not because of an implementation issue.

-- 

						K. Poon.
						[email-masked]