On Tue, Jul 28, 2009 at 11:18:05PM +0200, Michael T?xen wrote: > >I don't think that's what the RFC says, but I guess only the > >author(s) of > >the RFC could tell us what they really meant. Your interpretation > >doesn't > >make any sense to. > > Let us see the tracefile and I can tell you if that behaviour is the > one the authors of the RFC intended... Heh. I'm guessing that you're one of the authors then? I see you given credit in RFC 4960, but the only author listed at the top is R. Stewart. I've attached linux and BSD capture files, and the client and server test programs. The client just sends a request to the server, and then waits for a reply. The client loops four times and sleeps 2 seconds between iterations. I ran the client on a Fedora 10 laptop in all cases (kernel version 2.6.27.25) and did the wireshark capture on the same laptop. sctp_bsd72_server.cap is the capture when running the server on a FreeBSD 7.2 machine. sctp_linux_server.cap is the capture when running the server on a Fedora 10 desktop machine. A single iteration with the BSD server looks like: 7 2.000205 10.0.0.15 10.0.0.11 SCTP DATA 8 2.000501 10.0.0.11 10.0.0.15 SCTP SACK DATA 9 2.200484 10.0.0.15 10.0.0.11 SCTP SACK So one DATA packet from client to server, then the reply data packet from server to client with a bundled SACK, then the SACK from client to server to acknowledge the reply. The last SACK does have to wait for the SACK timer to expire; this is to be expected, since no more data is sent until the next iteration in a couple seconds. A single iteration with the Linux server looks like: 7 2.000161 10.0.0.15 10.0.0.12 SCTP DATA 8 2.000495 10.0.0.12 10.0.0.15 SCTP DATA 9 2.199995 10.0.0.15 10.0.0.12 SCTP SACK 10 2.200170 10.0.0.12 10.0.0.15 SCTP SACK > >In BSD's case, I *did* see it piggyback the SACK. > > I guess you did not specify SCTP_DATA_SACK_IMMEDIATELY in the send() > call... No, I didn't. If I had, I agree that no piggybacking would have been possible. That was what I was trying to say: from the trace, it did not look as though BSD was using the immediate SACK feature. --Doug.
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #include <unistd.h> #define PORT 12342 int main(int argc, char **argv) { int s, cc, i; struct sockaddr_in addr; in_addr_t destaddr = inet_addr("127.0.0.1"); if (argv[1]) destaddr = inet_addr(argv[1]); if ((s = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) { perror("socket"); exit(1); } memset(&addr, '\0', sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = destaddr; addr.sin_port = htons(PORT); char buf[] = "yo momma wears army boots"; struct iovec iov[1] = {{.iov_base = buf, .iov_len = sizeof(buf)}}; struct msghdr msg = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = iov, .msg_iovlen = sizeof(iov)/sizeof(iov[0]), .msg_control = NULL, .msg_controllen = 0, .msg_flags = 0 }; for (i = 0; i < 4; i++) { printf("Sending message to %s\n", inet_ntoa(addr.sin_addr)); if ((cc = sendmsg(s, &msg, 0)) < 0) { perror("sendmsg"); exit(1); } sleep(2); } return 0; }
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #define PORT 12342 int main(void) { int s, cc; struct sockaddr_in addr; if ((s = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) { perror("socket"); exit(1); } memset(&addr, '\0', sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(PORT); if (bind(s, (struct sockaddr *) &addr, sizeof(addr)) < 0) { perror("bind"); exit(1); } if (listen(s, 5) < 0) { perror("listen"); exit(1); } for (;;) { char buf[128]; struct iovec iov[1] = {{.iov_base = buf, .iov_len = sizeof(buf)}}; struct msghdr msg = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = iov, .msg_iovlen = sizeof(iov)/sizeof(iov[0]), .msg_control = NULL, .msg_controllen = 0, .msg_flags = 0 }; printf("Waiting for message\n"); cc = recvmsg(s, &msg, 0); printf("Got msg, len = %d\n", cc); sendmsg(s, &msg, 0); } }
Attachment:
sctp_bsd72_server.cap
Description: Binary data
Attachment:
sctp_linux_server.cap
Description: Binary data