------------------------------- README - SCTP PROTOCOL EXAMPLES ------------------------------- Author: Eduardo Gonzalez Vidal - Jan/2014 INTRODUCTION ------------ Stream Control Transmission Protocol is a transport layer protocol defined in 2000, that ensures reliable and in-sequence transport of messages like TCP, but with a message oriented characteristics like UDP. Additionally, it includes multihoming features that allow robust communication with fallback, and multistreaming for separating the flow of information in independant streams, that do not interfere with each other, thus preventing head-of-line blocking. This example illustrates these two important features of the SCTP protocol. THE EXAMPLES -------------------- The example is a client-server application that simulates the communication of two different types of sensor data from the client to the server (temperature and GPS data). Each is sent as an independent packet over a different stream. Thus, stream 0 communicates one type of data and stream 1 communicates the other type. The protocol assures in-sequence transport of each packet relative to its stream, and that stream only. In this example, the messages are sent alternating between temperature and GPS data. The source code for each program is: sctp_cli_mh.c sctp_serv_mh.c Within the source code of sctp_cli_mh.c you can select to add a delay between messages, and thus test the multihoming capacities of the protocol by manually shutting one of the available links. If the delay is removed, a great number of messages is sent per second, thus permiting the chance of a packet to be lost and the multistreaming capacities observed as a consequence. RUNNING THE EXAMPLES -------------------- The examples were designed and tested in Linux with an Ubunto based distribution. It is required to install lksctp-tools, libsctp-dev and libsctp1 packages, libraries and development tools before running. To compile the examples use e.g,: $gcc sctp_cli_mh.c -l sctp -o sctpCli $gcc sctp_serv_mh.c -l sctp -o sctpSer After the executables are created, run them on different machines (the same is also an option). First execute the server program as follows: $./sctpSer It will automatically print the addresses it was able to bind. For example, the program will print something similar to: Heartbeat interval 5000 Addresses binded: 3 Address 1: 127.0.0.1:20675 Address 2: 10.2.50.67:20675 Address 3: 192.168.1.197:20675 The client server will be able to address its packets to any one of these IP addresses (given it is visible). The port used for communication is pre-defined and can be modified in the source code. The next step is to run the client application and connect to the server, e.g,: $./sctpCli 192.168.1.197 After this the communication will begin immediately and the server will print the messages it recieves and additional information about the packages. It will also indicate the source IP of the package. SUGGESTED TESTS --------------- This requires two computers connected to the same local area network, with the possibility to connect via Ethernet or Wifi. Connect both computers to the network using both Ethernet and Wifi, so they have two addresses of the type 192.168.xxx.xxx, one for each interface. Then run the client program in one and the server client in the other, with a 1 second delay between each message sent. Connect to the Ethernet IP address of the server computer running the program from the client. The client will automatically begin sending messages from its Ethernet IP address (preferred over wifi) to the Ethernet address of the server. This will be visible in the recieved messages on the server side. Afterwards, remove the Ethernet cable on the server side. If the wifi connection was already established before you disconnect the cable, the program will automatically fallover to wifi and redirect the flow of packets on the client side. You will know this has ocurred because you will continue to recieve all the packets (in order and without loss!). Finally, remove the Ethernet cable on the client side. It will now not only direct the packets to the wifi IP address on the server side, but send them through his own wifi connection. The program wil detect Ethernet is no longer available and fallover to wifi. You will know this has happened as you will see the address of the recieved packets change on the server side. Again, no packet loss! Another test consists in removing the 1 second delay and connecting both computers to the network only through wifi. This will probably cause a packet loss eventually, so you can add a break in the server source code if it recieves two packages with the same stream identifier. If this ocurrs, it means multistreaming is doing its job, because in TCP, head-of-line blocking would not have allowed two consecutive temperature or GPS data messages to arrive. The fact this ocurrs means one of the packets was lost, and thus two messages of the same kind arrived at the server consecutively. If using TCP, this packet would not be passed to the application until the missing packet is recieved after retransmission from the client. This is not the case in SCTP, since each message type is being sent through an independent stream. ABOUT ----- These examples were written and tested for the class "Seminare of Computer Networks" at Universidad Tecnica Federico Santa Maria, Chile, on January 2014 as part of the final project.