[sctp-dev] Using SctpMultiChannel

[Chris Hegarty]

The SCTP package provides two programming model styles. ( below taken 
partly from the package description ):

   The one-to-one style supported by SctpChannel and SctpServerChannel,
   and the one-to-many style supported by SctpMultiChannel. The
   semantics of the one-to-one style interface are very similar to TCP (
   like ServerSocketChannel and SocketChanel). An SctpChannel can only
   control one SCTP association. The semantics of the one-to-many style
   interface are very similar to UDP (like DatagramChannel). An
   SctpMutliChannel can control multiple SCTP associations.

These two styles are taken from the Sockets API Extensions for SCTP [1]. 
I see that the one-to-many style does support a connect function, we 
could expose this through the SCTP API, in a similar way to how it is 
done in DatagramChannel.

I am curious about your need to use SctpMultiChannel. I do get the fact 
that you want the association to use the same local IP/port, but it is 
not correct to think that a branched (sctp_peeloff in native terms) will 
not incur additional OS resources. Taken from [1]:

  "After an association is established on a one-to-many style socket,
   the application may wish to branch off the association into a
   separate socket/file descriptor."

-Chris.


[1] http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-31

On 11/08/2011 14:30, Chris wrote:
> I see now that my reading comprehension isn't so good. So the multi-channel does create new associations also for incoming connections :)
>
> But what I think I would really be after is a connect() method on SctpServerChannel that spawned a new SctpChannel. If so I wouldn't have to go to the multichannel and its somewhat different way of working.
>
> BR,
>    Chris
>
> --- On Thu, 8/11/11, Chris<devnullaccount at yahoo.se>  wrote:
>
>> From: Chris<devnullaccount at yahoo.se>
>> Subject: Re: [sctp-dev] Using SctpMultiChannel
>> To: "Johan Lübcke"<johan.lubcke at symsoft.com>, "Chris Hegarty"<chris.hegarty at oracle.com>
>> Cc: "sctp-dev at openjdk.java.net"<sctp-dev at openjdk.java.net>
>> Date: Thursday, August 11, 2011, 3:13 PM
>> 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
>>>>
>>>
>>