Subject: Re: [Tsvwg] Section 7.1.3 sctpsocket-02.txt

From: [email-masked]
Date: Mon, 14 Jan 2002 18:05:53 +0530

Randall,
thanks for clarification
    i think there should be more clear explanation in this para that
 getsockopt  call with SCTP_INITMSG will return only the values set by user or
dafault
may be inherited from server socket ( in case of TCP style) and these values may
be different
from the actual values ( after stream negotaition ) . ofcouse these will be used
for future
associations.  and to get actual values use SCTP_STATUS ( if you add the new
fields)

i have one one doubt ragarding assoc_change notification
in TCP style interface
the scenerio is  a server socket (say A) is listening for connection
a connection request comes and connection is made successfully
now i should get assoc_change notification (assume it is enabled) on server
socket before accept      OR
assoc_change notification on new socket descriptor after accept call

my understanding is assoc_change should come on new socket after accept call

if it is implementation dependent issue still it should be same for ULP
i hope you understand my doubt
thank
yogesh

Randall Stewart <[email-masked]> on 01/14/2002 04:19:17 PM

To:   Yogesh Gahlaut/HSS@HSS
cc:   [email-masked]

Subject:  Re: [Tsvwg] Section 7.1.3 sctpsocket-02.txt

Yogesh:

To quote that section:

"
    Setting initialization parameters is effective only on an
    unconnected socket (for UDP-style sockets only future associations
    are effected by the change). With TCP-style sockets, this option is
    inherited by sockets derived from a listener socket.
"

You do not GET anything back from this request. If you do a
getsocketopt() with this parameter you will get back what the
current default is. For your example 2... This has nothing
to do with current associations but what FUTURE associations
will be setup with.

Now if you want the specific details on an association you
turn on the flag to receive association change events..

Which will cause you to receive a SCTP_ASOC_CHANGE event telling you how
many
streams you have in/out.

Now you do bring up a good point. If I don't have this on
and want to know how many streams there are there is no
way to tell..

Hmm.. maybe we should add two parameters to the SCTP_STATUS
structure to tell you the in/out streams..

R

[email-masked] wrote:
>
> Randall :
>      thanks for for answer. i have one more doubt ...
>   lets consider this sequence of events
>
>    open a udp socket .
>    make association with peer endpoint A with streams setting X  and got
> assoc_id 1
>    set some diifernt no of in and out streams using setsockopt
>   make another association with other peer endpoint B with streams setting Y
and
> got assoc_id 2
>   and now if i use getsockopt with socket option SCTP_INITMSG
>   what should i get stream info from assoc_id 1 or 2....
> the stream setting X and Y  may be different ( after stream negotaition )
> is this sequence valid or i am missing something
> i hope you understand my doubt .
>
> thanks
> yogesh
>
> Randall Stewart <[email-masked]> on 01/11/2002 08:42:32 PM
>
> To:   Yogesh Gahlaut/HSS@HSS
> cc:   [email-masked]
>
> Subject:  Re: [Tsvwg] Section 7.1.3 sctpsocket-02.txt
>
> Yogesh:
>
> Two things:
>
> First:
>
> The sctp_initmsg is used in the UDP model to start
> a new association with a peer (i.e. you are sending the
> INIT message out) and over-ride the default INIT parameters
> with the value found in the sctp_initmsg structure.
>
> So we have an app sending a message with a
> sendmsg() and putting the sctp_initmsg structure
> in a CMSG header to go with the first message you
> are sending. The sendmsg() call also includes the
> destination address in the msg_name field ... i.e. the
> sockaddr * of who you are sending (and INIT'ing) to.
>
> Second:
>
> If you are asking instead about notifications, i.e.
> the association just came up and how do I tell what
> parameters were negotiated in the streams counts
> etc.. you get this in a MSG_NOTIFICATION in the
> form of a
>
> struct sctp_assoc_change x;
>
> And it too is received via a recvmsg() call where
> the msg_flags field gets set to MSG_NOTIFICATION and the
> msg_name will have the peer that the association just came
> up with .. the data read will be the  sctp_assoc_change..
>
> Of course you must enable this event...
>
> Hope that helps...
>
> R
>
> [email-masked] wrote:
> >
> > hi all,
> >
> >   in section 7.1.3   the following structure is being used for returning the
> > SCTP_INITMSG option value
> >
> > struct sctp_initmsg {
> >        uint16_t sinit_num_ostreams;
> >        uint16_t sinit_max_instreams;
> >        uint16_t sinit_max_attempts;
> >        uint16_t sinit_max_init_timeo;
> >     };
> >
> >  Since it does not have any input parameter to differentiate in case of more
> > than
> > one association in UDP style socket .
> >
> > can anybody explain how to handle this case ?
> >
> > thanks
> > Yogesh
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
>
> --
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

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

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Mon, 14 Jan 2002 07:28:41 -0600

> associations.  and to get actual values use SCTP_STATUS ( if you add the new

We probably should :>

> if it is implementation dependent issue still it should be same for ULP

I don't understand this last line.. "should be same for ULP" what do
you mean... that even if it is implementation dependant the ULP should
see the same thing? Or something else?

> i hope you understand my doubt

No I think you need to do it AFTER the accept call. This is because
you really don't want the assoc-change event to show up 
on the listen() socket.. but the new one. Thus the socket does
not exist until after the accept() which creates the fd.

But maybe it should be implementation dependant... I would defintly
welcome other comments/opinions on this..

R

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 Jan 2002 19:30:39 -0800 (PST)

> welcome other comments/opinions on this..

First, I think apps using TCP-style socket will probably not
enable this notification.  What Randy suggested make sense.  But
then if we want to make it similar to UDP-style socket, the
notification should be sent to the listening socket.  After 
getting it, the app can do an accept().  I don't have preference
of one to the other.  It is probably safe to leave it
as implementation dependent for the moment, until we see a strong
reason to do it one way or the other.

							K. Poon.
							[email-masked]