Figure 10.4 shows our SCTP default client processing function.
sctp/sctp_strcli.c
1 #include "unp.h"
2 void
3 sctpstr_cli (FILE *fp, int sock_fd, struct sockaddr *to, socklen_t tolen)
4 {
5 struct sockaddr_in peeraddr;
6 struct sctp_sndrcvinfo sri;
7 char sendline [MAXLINE], recvline [MAXLINE];
8 socklen_t len;
9 int out_sz, rd_sz;
10 int msg_flags;
11 bzero (&sri, sizeof (sri) ) ;
12 while (fgets (sendline, MAXLINE, fp) != NULL) {
13 if (sendline [0] != ' [') {
14 printf ("Error, line must be of the form '[streamnum] text '\n");
15 continue;
16 }
17 sri.sinfo_stream = strtol (&sendline [1], NULL, 0);
18 out_sz = strlen (sendline);
19 Sctp_sendmsg (sock_fd, sendline, out_sz,
20 to, tolen, 0, 0, sri.sinfo_stream, 0, 0);
21 len = sizeof (peeraddr) ;
22 rd_sz = Sctp_recvmsg (sock_fd, recvline, sizeof (recvline),
23 (SA *) &peeraddr, &len, &sri, &msg_flags) ;
24 printf ("From str:%d seq:%d (assoc:0x%x):",
25 sri.sinfo_stream, sri.sinfo_ssn, (u_int) sri.sinfo_assoc_id);
26 printf ("%.*s", rd_sz, recvline);
27 }
28 }
1112 The client starts by clearing the sctp_sndrcvinfo structure, sri. The client then enters a loop that reads from the fp passed by our caller with a blocking call to fgets. The main program passes stdin to this function, so user input is read and processed in the loop until the terminal EOF character (Control-D) is typed by the user. This user action ends the function and causes a return to the caller.
1316 The client examines the user input to make sure it is of the form [#] text. If the format is invalid, the client prints an error message and re-enters the blocking call to the fgets function.
17 The client translates the user requested stream found in the input into the sinfo_stream field in the sri structure.
1820 After initializing the appropriate lengths of the address and the size of the actual user data, the client sends the message using the sctp_sendmsg function.
2123 The client now blocks and waits for the echoed message from the server.
2426 The client displays the returned message echoed to it displaying the stream number, stream sequence number, as well as the text message. After displaying the message, the client loops back to get another request from the user.
A user starts the SCTP echo server with no arguments on a FreeBSD machine. The client is started with just the address of our server.
freebsd4% sctpclient01 10.1.1.5 | |
[0]Hello | Send a message on stream 0 |
From str:1 seq:0 (assoc:0xc99e15a0) : [0]Hello | Server echoes on stream 1 |
[4]Message two | Send a message on stream 4 |
From str:5 seq:0 (assoc:0xc99e15a0) : [4]Message two | Server echoes on stream 5 |
[4]Message three | Send a second message on stream 4 |
From str:5 seq:1 (assoc:0xc99e15a0) : [4]Message three | Server echoes on stream 5 |
^D | Control-D is our EOF character |
freebsd4% |
Notice that the client sends the message on streams 0 and 4 while our server sends the messages back on streams 1 and 5. This behavior is expected from our server with no arguments. Also notice that the stream sequence number incremented on the second message received on stream 5, as expected.