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

From: [email-masked]
Date: Tue, 15 Jan 2002 19:00:48 +0530

Hi,

Comments below ..

Best Regards,
-Sandeep

Kacheong Poon <[email-masked]> on 01/15/2002 09:00:39 AM

Please respond to Kacheong Poon <[email-masked]>

To:   Randall Stewart <[email-masked]>
cc:   Yogesh Gahlaut/HSS@HSS, [email-masked] (bcc: Sandeep Mahajan/HSS)

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

> 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..

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.

Sandeep >> Third option would be to not send Endpoint UP notification at all at
Server side. Application waiting for events on server sockets ( either via
blocking accept OR via select) only needs to do an accept call to get the new
socket fd. To get the parameters of new association like peer address list and
number of negotiated streams (which would have returned to the application in
Endpoint UP notification), application can use API "sctp_getpaddrs" and
getsockopt with option "SCTP_STATUS". Provided numbe of negotiated streams
parameter is added in the sctp_status structure.

                                   K. Poon.
                                   [email-masked]

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

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