[sctp-dev] Basic Questions

[David Ryan]

Hi Chris,

thanks for the quick response.  Comments inline too..

On Fri, Jun 19, 2009 at 1:31 AM, Christopher Hegarty - Sun Microsystems
Ireland <Christopher.Hegarty at sun.com> wrote:

> Hi David,
>
> comments inline...
>
> David Ryan wrote:
>
>> Hi,
>>
>> I have recently downloaded the Client/Server example from Chris Hegarty's
>> Blog.  I've been playing around with it and getting a feel for SCTP.  My
>> environment is Java 7 b59 running on Open Solaris 2009.06  (in VMware Fusion
>> on OSX).
>>
> Great that you are playing around with this. I really appreciate the
> feedback/questions. Interesting environment, good to see that you are on
>  09.06


For any interested on lookers, I found it very easy to setup following this
guide.

http://wikis.sun.com/display/OpenSolarisInfo/How+to+Run+OpenSolaris+in+VMware+Fusion+for+Mac

I used the package manager to install eclipse.  Actually the only change
from the guide above was to increase the memory from 780mb to 1.5Gb.
Eclipse and/or java uses a lot of memory.
Of course I also installed Java7 which was easy too.


>
>
>  I changed the example code to send different sized packets and found that
>> the maximum size of data returned by receive was 16,000 bytes.  Is this the
>> exact same size of the underlying network packet?  I'm assuming it is and
>> that the packet size is large because it didn't actually go over a network.
>>
> I assume you are sending messages larger that 16,000 bytes but the receive
> is return an incomplete message, i.e. isComplete returns false, right?


Yes, I was sending packets larger than 16,000 bytes.  isComplete was always
returning true on the receiver; more on this below.


>
> The packet size does indeed look very large for a single PDU. I would
> suspect that several PDU's are available in the input buffer and being
> combined before returning to the user. Can you see the MTU of interface that
> you are sending/receiving on, 'ifconfig -a'?


I think you're right about this.  The MTU size was 1500 bytes.  I ended up
making a few other changes and ran my test again and found that I was
receiving upto 100,000 bytes in each message.  I must have been lucky
sending at the edge of a timer which caused the packets to split.  I found
that the underlying send/receive buffers were around 100,000 bytes and
received a message to large exception when trying to send larger packets.
ie

java.net.SocketException: Message too long
    at sun.nio.ch.SctpChannelImpl.send0(Native Method)
    at
sun.nio.ch.SctpChannelImpl.sendFromNativeBuffer(SctpChannelImpl.java:1005)
    at sun.nio.ch.SctpChannelImpl.send(SctpChannelImpl.java:973)
    at sun.nio.ch.SctpChannelImpl.send(SctpChannelImpl.java:948)
    at DaytimeClient$DataSender.run(DaytimeClient.java:146)
    at java.lang.Thread.run(Thread.java:717)

The API supports SCTP_DISABLE_FRAGMENTS socket option to disable the
> implementation from fragmenting messages. On your platform I suspect that
> this option is true by default. Can you check the value of this? Maybe you
> could set it to false to determine the exact PMTU, if it is not actually
> 16,000 which is may be.


I ran a few tests to retrieve all the socket options available.  On the
client I got the following:

disableFragments = Option not supported by protocol
explicit complete = Option not supported by protocol
fragment interleave = Option not supported by protocol
init max streams =
com.sun.nio.sctp.SctpStandardSocketOption$InitMaxStreams at 7[maxInStreams:32maxOutStreams:32]
no delay = false
primary address = Option not supported by protocol
linger = -1
rcv buffer = 102265
snd buffer = 102400

I thought it was odd that some of those options weren't supported.  I tried
the same thing on the server.  I got different exceptions/results from doing
them on the SctpServerChannel and SctpChannel.

On the SctpServerChannel the following were returned:

disableFragments = 'SCTP_DISABLE_FRAGMENTS' not supported
explicit complete = 'SCTP_EXPLICIT_COMPLETE' not supported
fragment interleave = 'SCTP_FRAGMENT_INTERLEAVE' not supported
init max streams =
com.sun.nio.sctp.SctpStandardSocketOption$InitMaxStreams at 7[maxInStreams:32maxOutStreams:32]
no delay = 'SCTP_NODELAY' not supported
primary address = 'SCTP_PRIMARY_ADDR' not supported
linger = 'SO_LINGER' not supported
rcv buffer = 'SO_RCVBUF' not supported
snd buffer = 'SO_SNDBUF' not supported

On the SctpChannel (returned from ssc.accept() ) the following were
returned:

disableFragments = Option not supported by protocol
explicit complete = Option not supported by protocol
fragment interleave = Option not supported by protocol
init max streams =
com.sun.nio.sctp.SctpStandardSocketOption$InitMaxStreams at 7[maxInStreams:32maxOutStreams:32]
no delay = false
primary address = Option not supported by protocol
linger = -1
rcv buffer = 102400
snd buffer = 102400

One thing to note is that the exception returned from the SctpServerChannel
getOption was different from the SctpServerChannel getOption call.  It would
probably be nicer if these were the same.

I tried playing around with the various options available from MessageInfo
and found that setting complete to true or false on the sender didn't change
anything; on the receiver the setting always returned true.  I also found
the the TTL on the receiver was always zero, although I'm not sure if this
is expected.

Another thing I noticed was that InvalidStreamException is an undeclared
exception.  It would be nice if this extended from IOException and could be
caught in the declared catch block.


>
>
>  Is it possible to discover the PMTU size from the API so that a protocol
>> can be optimized for SCTP?
>>
> It is not currently possible to retrieve the PMTU through the API, but it
> should possible to implement an implementation specific socket option to
> support this, and I could add it to the API if necessary.
>
> Are you sure you want to do this? The reason I ask is that the PMTU may be
> different for the different routes on an association with multiple
> interfaces. Typical applications will not directly control which destination
> address to use when sending, so trying to size your messages to an specific
> size based on the PMTU may not be the best approach. Or do you have a
> different scenario?


At the moment I'm not exactly sure if I need the PMTU or not.  This is my
first experience with SCTP so am attempting to work out how best to build
application protocols to use it.  At the most basic level I'm wondering how
to construct application level framing packets.  Do I rely on SCTP to frame
the packets or do I need to include start of packet headers and such for
framing?

I figure there's probably two options.  If the PMTU is available and
guarantees that each message is received completely then I can split large
messages into packets and know that any headers will be at the start of the
message buffer.  This can be easily split off before passing data to
applications, etc.  If the PMTU is not available then I can't rely on the
message buffer being aligned and will need to use standard TCP style
protocol methods of assuming that data is an unbounded stream.  The third
option is that SCTP handles message boundaries even for large packets and
any size packet up to the send buffer size will be gauranteed to arrive at
the destination with the message boundary intact.  In this case I still need
headers to confirm the start of packets, but have a slightly easier time
finding the end of the packet (ie won't need to use too many offsets for
start of following packets into buffers, etc).  If you or anyone on the list
has any experience with this I'd appreciate some input.

Personally, I like the idea of having the PMTU and exposing the underlying
IP nature of protocols to higher level applications protocols.  I see this
as one of the many nice features in SCTP.

Eventually the plan is to build a couple of layers above SCTP.  The first
layer being a kind of SSL (based on web of trust concepts) and second being
a session layer for managing the streams.  Hopefully I'll end up with a
higher level API which can assign bi-directional streams/packets to higher
level applications.

Thanks again for your help,
David.


>
>  Also, great to see SCTP on Java.  Disapointing its not on all platforms
>> yet, but I'm sure that will be fixed in good time.
>>
> Yes, hopefully over time other platforms/ports can be supported.
>
> -Chris.
>
>
>> Regards,
>> David.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/sctp-dev/attachments/20090619/77ace518/attachment.html