Getting Started with SCTP

‹prev | My Chain | next›

As I near the end of my three month window for writing SPDY Book, I am beginning to fret over the things that I have not covered. The biggest, most worrisome outstanding bit for me at this point is lack of counterpoint.

So up tonight, I am ready to give SCTP (Stream Control Transmission Protocol) a whirl. SCTP is a transport layer protocol, so it is not a direct competitor to SPDY, which sits atop HTTP in the application layer). It still aims to solve some of the same problems as SPDY so it is worth a go.

As a potential replacement for TCP/IP, my initial impressions are that it stands no chance. It takes me quite a bit of digging before I even come across a simple example of how to test this stuff. How can it possibly a serious possibility of being installed on computers across the world?

First up, I install lksctp-tools. Fortunately, no compilation is required on Ubuntu/Debian. Rather I can pull it directly from apt-get:

sudo apt-get install lksctp-tools

Before actually trying things out, I check that Wireshark can grok SCTP. Under Analyze, I choose Enabled Protocols and see:



Cool beans. Wireshark rocks.

I also check through the filtering options on Wireshark:



I do not think that I will need them tonight. Good to know they are there. For now, I am content to capture anything SCPT, so a Wireshark capture filter of sctp will suffice.

With a live SCTP capture running in Wireshark, I start up my server. I use the sctp_darn utility from lksctp-tools:

➜  spdybook git:(master) sudo sctp_darn -H 0 -P 250 -l
sctp_darn listening...

In a separate window, I start my client (the args are directly from the linked tutorial):

➜  spdybook git:(master) sudo sctp_darn -H 0 -P 260 -h 127.0.0.1 -p 250 -s
sctp_darn ready to send...
0:260-127.0.0.1:250> 

Checking Wireshark, I see that no traffic has been sent:



I am unsure if this is a feature of SCTP or just how the sctp_darn utility works. Normal TCP/IP sockets would have sent data at this point. Regardless, I move ahead with my investigation.

Back in my client window, I send data:

0:260-127.0.0.1:250> Hello SCTP!!!
Recieved SCTP_COMM_UP
New connection, peer addresses
127.0.0.1:250
192.168.0.20:250
0:260-127.0.0.1:250> 

In the server terminal, I find:

Recieved SCTP_COMM_UP
NOTIFICATION: ASSOC_CHANGE - COMM_UP
SNDRCV
   sinfo_stream 0
   sinfo_ssn 0
   sinfo_flags 0x0
   sinfo_ppid 0
   sinfo_context 0
   sinfo_tsn     238345625
   sinfo_cumtsn  0
   sinfo_assoc_id  4
DATA(15):  Hello SCTP!!!.

Well that wasn't so bad after all!

Checking things out in Wireshark, I see the famed 4 way, SCTP handshake (avoids TCP's SYN flooding):



Last up tonight, I give this a try over the network. On my server, I run the same server command as above. Similarly, on my laptop, I run the same command as early, only this time I supply my server's hostname:

➜  spdybook git:(master) ✗ sudo sctp_darn -H 0 -P 260 -h londo -p 250 -s
[sudo] password for cstrom: 
sctp_darn ready to send...
0:260-londo:250> Hello!
Recieved SCTP_COMM_UP

And, amazingly, it just works on my server:

cstrom@londo:~$ sudo sctp_darn -H 0 -P 250 -l
sctp_darn listening...
Recieved SCTP_COMM_UP
NOTIFICATION: ASSOC_CHANGE - COMM_UP
SNDRCV
   sinfo_stream 0
   sinfo_ssn 0
   sinfo_flags 0x0
   sinfo_ppid 0
   sinfo_context 0
   sinfo_tsn     184442484
   sinfo_cumtsn  0
   sinfo_assoc_id  1
DATA(32):  Hello Londo, I'm talking SCTP!.

I do not know why I expected trouble there, but it does just work on my Ubuntu machines. I have to admit that there may be something to this SCTP stuff after all.

That will do for tonight. Up tomorrow, I will see if I can put SCTP in situations more akin to what SPDY is trying to solve.


Day #69