1. Effective TCP/IP Programming Snader, ETCP 중심으로

2. Understand IPv4 Addressing

3. IPv4: originally Classful Addressing  Special address  Host ID = 0: network address  Network ID = 0, host ID = 0  i.e 0.0.0.0 means this network  127.x.y.z : “looped back”  Host ID = all 1s : broadcasting  NAT address  10/8  172.16/12  192.168/12  Broadcast address  255.255.255.255  Limited broadcast  router 밖에는 나가지 못함  190.50.255.255  Network-directed broadcast  그 네트워크까지 가서 네트워크 내에 broadcast  190.50.1.255/24  Subnet-directed broadcast  190.50.1.0/24 subnet 내에 broadcast IPv4 address 는 host 의 address 가 아니라 interface 의 address 이다.

4. Subnet  Network address  IP address && mask  Network ID 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 network consisting of 3 subnets subnet 223.1.1.0/24 223.1.2.0/24 223.1.3.0/24 223.1.0.0/16 CIDR (Classless Inter-Domain Routing)  Subnetting + suppernetting

5. Develop and Use Application “Skeletons”

6. Making UNIX/Windows Compatible UNIX: bsd/skel.hWindows: win/skel.h wincompat.c: Window 에서 socket 을 생성전에 call 해야

7. TCP Server Skeleton tcpserver.skel: “mclab.hufs.ac.kr” or “203.254.68.114” or “” -- server “http” or “80”

8. TCP Server Skeleton - Cont’d Usage: % myserver [local_addr | local_name] {local_port | service} Example: %myserver 15000 %myserver localhost http

9. TCP Client Skeleton tcpclient.skel: Usage: % myclient {peer_addr | peer_name} {peer_port | service} Example: % myclient 203.253.70.5 15000 % myclient www.hufs.ac.kr http

10. UDP Server & Client Skeleton udpserver.skel:udpclient.skel:

11. Build Your Own Library and Use It ! etcp.h

12. TCP Client & Server Starting Functions Host name or IP addr or “” (my addr for server) “http” or “80”

13. UDP Client & Server Starting Functions

14. Remember that TCP is a Stream Protocol

15. TCP is a Stream Protocol  No message boundary, just a byte stream  TCP application 에서 하나의 message 를 send() 했다고 해서 recevier application 에서 그 message 를 한 덩어리로 recv() 되는 것이 아니다.  Message 를 send() 했어도 TCP segment 에 언제, 어떻게 실릴지 모른다. (buffering 되기 때문 )  Recv() 하면 몇 byte 읽힐지 모른다.  If you want to read exactly n bytes ??  If you want to make a record ???  Use end-of-record mark. e.g) new line  Handle variable records (using fixed header) #include /* UNIX */ #include /* Windows */ int recv (SOCKET s, void *buf, size_t bufsize, int flags); int read (SOCKET s, void *buf, size_t bufsize);/* UNIX */ Returns: # of bytes read (>0), 0 if received FIN and no more data, -1 on failure int send (SOCKET s, const void *buf, size_t len, int flags); int write (SOCKET s, const void *buf, size_t len);/* UNIX */ Returns: # of bytes transferred on success, -1 on failure 메시지를 읽을 user buffer 의 크기 즉, 최대로 읽을 수 있는 크기 Socket send buffer 에 저장할 메시지 길이

16. Use End-of-record mark: read a line lib/readline.c:

17. Read n bytes and Read a variable-length record Record Length Other Header Data Variable Data lib/readn.c: lib/readvrec: #include “etcp.h” int readn (SOCKET s, char *buf, size_t len); Returns: # of bytes read, -1 on failure int readvrec (SOCKET s, char *buf, size_t len); Returns: # of bytes read, -1 on failure len cnt bp Header size Network byte order

18. Example: Client/Server using variable records vrc.c: vrs.c:

19. Don’t Underestimate the Performance of TCP

20. TCP versus UDP  TCP  connection-oriented  reliable  byte stream  Application: typically concurrent server  SMTP(Simple Mail Transfer Protocol)  Telnet  FTP  HTTP  NNTP(Network News TP)  UDP  connectionless  unreliable  datagram  Applications: typically iterative server  SNMP(Simple Network Management Protocol)  TFTP(Trivial FTP)  BOOTP(Bootstrap Protocol)  DHCP(Bootstrap Protocol)

21. TCP 는 충분히 Optimize 되어 있다.  통상적인 TCP segment 수신 루틴 : 30 instructions (excluding checksum)  ACK 도 piggy-back  섯불리 UDP 를 사용하지 말라.  But, a single request-response 로 끝나는 transaction 에서는 TCP 는  Connection set-up: RTT 소요  Connection release: 적어도 RTT 소요

22. A UDP Source and Sink udpsource.c: udpsink.c: Record of length 0 i.e. end-of-record mark Set UDP socket receive buffer size 실제 5,000 개의 datagram 을 buffering 할 수는 없다. 왜냐 하면, 시스템에서 허용하는 socket receiver buffer 의 최대 크기는 이보다 훨씬 작기 때문이다 ( 수십 KB). UDP datagram 은 lost 될 수 있다 !! 1.Network congestion (no congestion cotrol) 2.Recv buffer overflow (no flow control)

23. A TCP Source and Sink tcpsource.c: tcpsink.c: Options: -s sndsz -b sndbufsz -c blks Set TCP send buffer size Set TCP receive buffer size

24. Comparison of TCP and UDP Performance  LAN 에서 UDP 가 TCP 보다 20% 정도 성능이 우수했음  그러나, UDP 에서는 lost 가 많이 발생함 (no flow control)  Loopback interface( 같은 host 내 ) 에서는 TCP 가 UDP 보다 훨씬 성능 우수했음  Local host 의 MTU 는 16,384 B (BSD)  Ethernet 의 MTU 는 1,500 B

25. Avoid Reinventing TCP  Any reasonably robust UDP application must provide  Error recovery: reTx a request if not received a response within RTO  Sequencing: ensure that replies are matched correctly to requests  Flow control: if server’s reply can consist of multiple datagrams, prohibit overflow of client’s recv buffer Cause to rewrite TCP  TCP 는 kernel 에서 처리되기 때문에 application 에서 reliable protocol 을 구현하는 것보다 실제 빠르다.

26. When to Use UDP instead of TCP  Adv. Of UDP  supports broadcasting and multicasting  no overhead for connection setup or teardown  UDP requires 2 packets to exchange a request and a reply  TCP requires about 10 packets to exchange assuming new TCP connection is established for each request-reply exchange  Features of TCP that are not provided by UDP  positive ACK, reTx of lost packet, duplicate packet detection, sequencing of packets  windowed flow control  slow start and congestion avoidance  Recommendation of UDP Usage  must be used for broadcast or multicast applications  desired level of error control must be added  can be used for simple request-reply applications  error detection must be needed  should not be used for bulk data transfer

27. Realize that TCP is a Reliable Protocol, Not Infallible Protocol

28. TCP is a Reliable Protocol, Not Infallible Protocol  2 peer 간에 connection 이 유지되는 한 TCP 는 ordered and uncorrupted delivery 를 보장한다.  Application 은 통신이 불가능함을 모르고 데이터를 보낼 수 있고, 따라서 목적지에 delivery 되지 못하는 경우가 발생한다.  TCP 는 data 를 보내봐야 실제 peer TCP 와 통신 가능한지 확인 가능 (ACK 를 받아 봐야 ) 또는, 2 시간 이상 데이터 교환이 없을 경우에나 통신 불가능을 확인 할 수 있음  교환할 데이터가 없어도 주기적으로 교환해야  heart beat mechanism 구현 필요  Application 은 send()/recv() 가 error return 되었을 때야, 통신 불가능함을 알게 된다.  failure 처리  통신 불가능한 경우 ( 실제 connection 이 유지되지 않는 경우 )  Network outage (due to router or link failure)  Peer app crashes  Peer host crashes

29. Network Outage  Inside TCP  Segment 보낸 후 ACK 가 없으면, 12 번 ReTx 한다 ( 약 9 분 걸림 )  여전히 ACK 를 받지 못하면, set socket pending error (ETIMEOUT)  Inside IP/ICMP  IP datagram 을 forwarding 할 수 없으면 (router 나 link 장애로 인해 ), ICMP host unreachable/network unreachable message 를 source 로 보낸다.  이 메시지를 Source IP 가 받으면, set socket pending error (ENETUNREACH/EHOSTUNREACH)  Socket Pending Error  Send() returns on failure  send buffer 에 쓰는 것이 실패를 의미  실제 보낸 데이터가 peer 에게 전달할 수 없음은 한참 뒤에나 알 수 있다.  Kernel 은 이와 같은 error 가 발생하면, 해당되는 socket 에 pending 시켜 놓는다  Socket API call 이 이루어질 때, error return 하면서 errno 에 설정한다.

30. Peer App Crashes  When peer app crashes, Local app is  In recv(): return 0  통상적인 절차로 종료  In send(): normal return  But, sent data is lost. Local connection 을 강제 close. Error is pending.  Send()/recv(): error return (ECONNRESET)  Send()/recv(): r rror return (EPIPE)  Peer app crashes(killed) 1. Call exit(), implicitly 2. Call close() in exit() 3. TCP: send FIN FIN data RESET No connection ! Not delivered to peer app

31. Ways to Detect Various TCP Condition

32. Peer app crashes – an example tcprw.c: count.c: killed

33. Peer Host Crashes  Local app  Connection set-up  Send(): normal return  But sent data is lost  Error is pending (ETIMEOUT) after retransmitting 12 times(9 min)  or error is pending (EHOSTUNREACH or ENETUNREACH) by ICMP  Peer host crash  No TCP there, so no TCP response data No TCP/IP Protocol !

34. Remember that TCP/IP is Not Polled No notification when connectivity is lost

35. Heartbeats  데이터를 보내 보지 않고서는 peer 와 통신 가능 여부를 알 수 없다  통신 불가능함에도 불구하고 데이터를 보내면 lost 됨 ( 송금했는데 못 받았으면 ???)  데이터 교환과 별도로 상대가 살아 있는지 주기적으로 check 해 봐야 함  hearbeat 필요  C/S 가 여러가지 msg type 을 교환하는 경우  Heartbeat msg 에 새로운 type 을 할당  C/S 가 byte stream 으로 교환하는 경우  Hearbeat 과 data 를 구분할 수 없음  Hearbeat 에 대해 별도 TCP connection 설정하여 구분  Or, Hearbeat 에 대해 OOB msg 로 교환  (send/recv() 에서 flag 를 OOB 로 설정 )

36. Hearbeat Client – msg type heartbeat.h: hb_client.c:

37. Heartbeat Server - msg type hb_server.c:

38. Hearbeat Client – separate connection hb_client2.c:

39. Hearbeat Server – separate connection hb_server2.c:

40. Be Prepared for Rude Behavior from a Peer

41.  Checking for client termination  Checking for valid input  UNIX utility program 중 6 ~ 43 % 가 인위적으로 생성한 random input 으로 시험했을 때 죽었음

42. Read a line lib/readline.c: len cnt bpb 0 bufptrbufx From socket Buffering C string 은 ‘\0’ 를 append 해야 함 Line >= 2 bytes

43. Consider Letting inetd Launch Your Application

44. inetd daemon  Problems starting with /etc/rc(without inet daemon)  All the servers contains nearly identical startup code  Each daemon takes a slot in process table, but asleep most of time  /etc/inetd.conf file specifies the services that the superserver inetd is to handle

45. Steps performed by inetd dup2(sockfd, 0); dup2(sockfd, 1); dup2(sockfd, 2); close(sockfd); Open descriptor 들은 fork 시 copy 되고 Exec 후에도 유지된다. Exec 후에 Peer 를 알 수 있는 방법은 ?

46. Consider Using Two TCP Connections

47. Concurrent Input/Output processes  One-connection architecture  Xout 에서 send 할 때 pending error 는 xin 에서 recv 해야 알 수 있다  Xin  mp  xout 으로 알려 줘야 함  Two connection architecture  별도의 connection 에 대해 socket pending error 가 있는지 testing 가능  Using select() readability

48. Example xout1.c:

49. Making Your Applications Event Driven

50. Making Your Apps Event Driven  Types of events in protocols and networked application  Packet arrival  User input  Timeout  API call  만일, API 도 UNIX domain socket( 일종의 socket descriptor 임 ) 이라면 select() 로 API call 이 발생했음을 확인 가능  다만, select() 는 timeout 은 하나만 가능  How to support multiple timeouts using select() ?  You can make it ! select() 로 확인 가능 (Ready or timeout? )

51. Timers in UNIX/Linux  Using SIGALRM signal: 초 단위  Interval timer: 실제는 10 msec 단위로 작동  select(): 실제 10 msec 단위로 작동 signal(SIGALRM, handler); // or sigaction(…) … alarm(seconds);// set timeout timer … void handler(in signo) { …. };// actions in timeout event #include int getitimer(ITIMER_REAL, struct itimerval *value); int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue); struct itimerval { struct timeval it_interval; /* next value */ struct timeval it_value; /* current value */ }; struct timeval { long tv_sec; /* seconds */ long tv_usec; /* microseconds */ };

52. Multiple Timeouts using select() #include “etcp.h” int tselect( int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *exceptset ); Returns: # of ready events, 0 if no remaining events, -1 on error unsigned int timeout( void (*handler)(void *), void *arg, int msec ); Returns: timer ID to be used in untimeout call void untimeout( unsigned int timerid ); /* call retransmit(packet) after 1500 msec (timeout) */ rxtimer = timeout(retransmit, (void *) packet, 1500 ); UItimer = timeout(useridle, NULL, 30000); … n = tselect(maxfdp1, &readset, &writeset, &exceptset ); … // if received ACK, untimeout(rxtimer); // reset the timer Examples

53. Tselect() source from ‘etcp’ lib/tselect.c

57. Internet Checksum Algorithm