[sctp-dev] Using SctpMultiChannel

Chris devnullaccount at yahoo.se
Thu Aug 11 06:13:29 PDT 2011


Hi Chris and Johan

big thanks for the replies. 

I guess I could try send(), but I won't have any data to send initially but would like to have the conneciton up so it sounds a bit messy compared to my current code. But with lack of other options, I'll try it.
Would the association change be a COMM_UP event with a newly-created Association? And I guess that means the "attachment" will be null when reaching the handler... 

Chris Hegarty said:
> It would appear that you want SctpChannel semantics but not
> the overhead 
> of creating a new socket for each association. But once
> branched the 
> returned SctpChannel will be assigned its own socket.
> 

Does it? As far as I understood RFC4960, you use the same *socket* (since I'm using the same local IP/port) that handles multiple different associations. So I'd like a new association, which I guess is an SctpChannel but still bound to the same socket. But maybe that's what you mean and I'm just twisting words :)

I'm very surprised by the difference between the SctpServerChannel and SctpMultiChannel since they are very similar in what they do. Could I pervert the SctpMultiChannel to do channel.register(OP_ACCEPT) and channel.accept() in a similar way as to using "send()" to create a connect()? 
I will need to run a single socket with that can do both accept() and connect() on the same port, and currently I'm not sure of which of these classes supports that.

BR,
  Chris



--- On Thu, 8/11/11, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> From: Chris Hegarty <chris.hegarty at oracle.com>
> Subject: Re: [sctp-dev] Using SctpMultiChannel
> To: "Johan Lübcke" <johan.lubcke at symsoft.com>
> Cc: "Chris" <devnullaccount at yahoo.se>, "sctp-dev at openjdk.java.net" <sctp-dev at openjdk.java.net>
> Date: Thursday, August 11, 2011, 2:59 PM
> 
> 
> On 08/11/11 01:25 PM, Johan Lübcke wrote:
> > I had the same problem and I ended up doing a "send"
> call to the remote address. That way I get a
> AssociationChangeNotification with an association id that
> can be passed to "branch".
> 
> Yes, this would be the best way to achieve what you are
> looking for.
> 
> SctpMultiChannel is a little like a datagram socket, in
> that it can send 
> and receive messages to/from remote peers without
> explicitly setting up 
> an association, i.e. no connect is required. The class
> description and 
> send method describe this:
> 
>    "The channel will implicitly setup a new
> association whenever it
>     sends or receives a message from a remote
> peer if there is not
>     already an association with that peer."
> 
> It would appear that you want SctpChannel semantics but not
> the overhead 
> of creating a new socket for each association. But once
> branched the 
> returned SctpChannel will be assigned its own socket.
> 
> -Chris.
> 
> 
> > This seems a bit awkward but it works. (Especially
> since I need to have some actual data to send already when I
> want to connect to the remote side). Doing a "connect" would
> have been more natural.
> 
> 
> 
> >
> > If there is a better way I am equally interested!
> >
> >    / Johan
> >
> >
> > 11 aug 2011 kl. 14.03 skrev Chris:
> >
> >> Hi,
> >>
> >> I'm trying to use SctpMultiChannel to get multiple
> associations on the same socket (same local port/IP but
> different remote endpoints), but I can't for the life of me
> figure out the API (http://openjdk.java.net/projects/sctp/javadoc/com/sun/nio/sctp/SctpMultiChannel.html)
> >>
> >> I get that I should do SctpMultiChannel.open() to
> create an instance and that I should bind it to my local
> address(es).
> >> But then I want to use something like connect()
> (like on a regular SctpChannel), but there's no such method,
> or anything similar as far as I can see. And the only way to
> get a regular SctpChannel out of this class seems to be
> branch(Accociation), but that's not either an option since
> I  need to have an association to call that.
> >>
> >> What am I missing?
> >>
> >> TIA,
> >>   Chris
> >
> 


More information about the sctp-dev mailing list