1. CS 3214 Computer Systems
Lecture 22
Godmar Back

2. Some of these slides are substantially derived from slides provided by Jim Kurose & Keith Ross. Copyright on this material is held by Kurose & Ross. Used with permission. The textbook is Computer Networking: A Top Down Approach Featuring the Internet Jim Kurose, Keith Ross, Addison-Wesley, July 2004
Part 2
Networking
CS 3214 Fall 2011

3. Socket Programming
UDP & TCP

4. Network Socket Programming
Socket: (narrow definition:) a door between application process and end-end-transport protocol (UDP or TCP)
process
Stack w/
buffers,
variables
socket
controlled by
application
developer
operating
system
host or
server
internet
CS 3214 Fall 2011

5. Socket Programming Socket API introduced in BSD 4.1 UNIX, 1981
a host-local,
application-created,
OS-controlled interface (a “door”) into which
application process can both send and
receive messages to/from another application process
socket
Socket API
introduced in BSD 4.1 UNIX, 1981
explicitly created, used, released by apps
used for both local and remote communication
CS 3214 Fall 2011

6. BSD Socket API API – Application Programming Interface
Provides access to services
Specified in C language
Implemented on many platforms in one way or the other
(Windows: WinSock2, CSocket MFC classes for BSD-like look)
Sockets (in Unix) are file descriptors
General idea: writing to the socket is sending data to network, reading from socket is receiving data
Good because read(2), write(2), close(2) and others (select(2), poll(2), ioctl(2), SIGIO, fcntl(2)) can be reused
Bad because suggest orthogonality if where there is none
Other languages provide separate mapping, often thin veneers over BSD sockets (e.g., java.net.Socket)
CS 3214 Fall 2011

7. Addressing
For UDP/IP or TCP/IP socket communication, generally need 4 parameters:
Source Identifier (32-bit IPv4 or 128-bit IPv6 Address)
Source Port (16-bit)
Destination Identifier (32-bit IP or 128-bit IPv6 Address)
Destination Port (16-bit)
Notice that the relationship of “local” and “remote” (also called “peer”) to source/destination depends on direction of communication
Note:
UDP uses only Destination (IP+Port) for demultiplexing
TCP uses Source + Destination
(quadruple: Src IP, Src Port, Dst IP, Dest Port)
CS 3214 Fall 2011

8. Addressing in IPv4 IP address interfaces, not hosts
IP address interfaces, not hosts
Sets of interfaces form subnets
Subnets share common prefix
Route to CIDR-ized subnet addresses
a.b.c.d/x
Within subnet, reach destination directly
CS 3214 Fall 2011

9. Internet Ethernet LAN 1 60 Machines R1 PPP Link 2 Subnet address: R1
PPP Link 2
Subnet address:
/26
Default gateway:
/30 R2
PPP Link 1
/30
Ethernet LAN 2
120 Machines R3
Subnet address:
/25
Default gateway:
CS 3214 Fall 2011

10. UDP Sockets: Overview Client Server socket() socket()
connect() (optional)
bind()
send()
acts like
sendto()
recvfrom()
recv()
acts like
recvfrom()
sendto()
Client Server
CS 3214 Fall 2011

11. int socket(int domain, int type, int protocol)
domain: PF_INET, PF_UNIX, PF_INET6, ….
type: SOCK_DGRAM (for UDP), SOCK_STREAM (for TCP), …
protocol:
0 for Unspecified (or IPPROTO_UDP or IPPROTO_TCP)
returns integer file descriptor
entirely between process and OS – no network actions involved whatsoever
man pages: ip(7), udp(7), tcp(7), socket(2), socket (7), unix(7)
type “man 2 socket”, “man 7 socket”
CS 3214 Fall 2011

12. int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen)
sockfd: return by socket()
my_addr: “socket address”
addrlen
length of address (address is variable-sized data structure)
“binds” socket to (local) address specified
This affects network protocol namespace, but no information is transmitted over network
Typically: one socket per port, exception: multicast
CS 3214 Fall 2011

13. How are addresses represented?
struct sockaddr { /* GENERIC TYPE, should be “abstract” */
sa_family_t sa_family; /* address family */
char sa_data[14]; /* address data */ };
/* This is the concrete “subtype” for IPv4 */
struct sockaddr_in {
sa_family_t sin_family; /* address family: AF_INET */
u_int16_t sin_port; /* port in network byte order */
struct in_addr sin_addr; /* internet address */
/* Internet IPv4 address. */
struct in_addr {
u_int32_t s_addr; /* address in network byte order */ };
/* IPv6 address */
struct in6_addr {
union
uint8_t u6_addr8[16];
uint16_t u6_addr16[8];
uint32_t u6_addr32[4];
} in6_u;
CS 3214 Fall 2011

14. More on bind(2) Address specified is the “local” address
Which is destination for receive and source for sends.
sin_addr.s_addr useful for “multi-homed” hosts, otherwise use INADDR_ANY
sin_port may be zero if any port would do
Use getsockname() to retrieve assigned port
s_addr and sin_port are specified in network byte order
This convention holds throughout socket API
getaddrinfo() prepares suitable structs
CS 3214 Fall 2011

15. sendto(2), recvfrom(2) s, buf, len as in read/write
ssize_t sendto(int s, const void *buf, size_t len, int flags, const
struct sockaddr *to, socklen_t tolen);
ssize_t recvfrom(int s, void *buf, size_t len, int flags,
struct sockaddr *from, socklen_t *fromlen);
s, buf, len as in read/write
flags: MSG_OOB, MSG_PEEK – mostly 0
to/from are of type struct sockaddr_in
These are remote/peer addresses: where did the packet come from, where should it be sent to
NB: fromlen is value-result!
CS 3214 Fall 2011

16. Then what does connect() do???
UDP & connect(2)
Then what does connect() do???
No notion of connections in UDP
connect(2) can be used to tell OS “default destination” for future sends
Then can use send(2) and write(2) instead of sendto(2), or can omit the destination address in sendto(2)
What does “ECONNREFUSED” mean for UDP?
Courtesy extended by other nodes which send ICMP packet saying “no one’s listening for UDP packets at the port number you sent it to”
OS relayed this information to UDP application
CS 3214 Fall 2011

17. UDP Demultiplexing Payload Payload Payload
S: :3045 D: :80
Payload
S: :???
sendto( :80)
socket()
bind(*, 80)
S: :80
socket()
S: :3045
recvfrom(&from) from: :3045
recvfrom(&from) from: :512
S: :512 D: :80
Payload
recvfrom(&from) from: :512
S: :53
bind(*, 53)
S: :512
bind( ,512)
S: :512 D: :53
Payload
CS 3214 Fall 2011

18. TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data:
point-to-point:
one sender, one receiver
reliable, in-order byte stream:
no “message boundaries”
pipelined:
transmission proceeds even while partially unack’ed data
send & receive buffers
full duplex data:
bi-directional data flow in same connection
connection-oriented:
handshaking (exchange of control msgs) init’s sender, receiver state before data exchange
flow controlled:
sender will not overwhelm receiver
CS 3214 Fall 2011

19. TCP Sockets Provide reliable byte-stream abstraction
In-order, reliable delivery of bytes
Bounded buffer abstraction with flow control
Send may block if receiver application has not drained the buffer
Connection-oriented
Client must connect(2)
Server performs “passive open” using accept(2)
CS 3214 Fall 2011

20. TCP Sockets: Overview Left side: client Right side: server socket()
listen()
socket()
connection
setup
connect()
accept()
bind()
write()
read()
Left side:
client
Right side:
server
read()
write()
connection
shutdown
close()
close()
CS 3214 Fall 2011

21. int connect(int sockfd, const struct sockaddr *peeraddr, int addrlen)
sockfd: returned by socket()
peeraddr: peer’s address (type sockaddr_in)
this call initiates hand-shake with server
CS 3214 Fall 2011

22. listen(2), accept(2) addr: accepted peer’s (aka client) address
int listen(int s, int backlog)
int accept(int s, struct sockaddr *addr, int *addrlen);
addr: accepted peer’s (aka client) address
of type sockaddr_in
listen() must precede accept
No network traffic, but informs OS to start queuing connection requests
accept() returns new socket
But does not assign new port – why not?
CS 3214 Fall 2011

23. TCP Demultiplexing 10.0.0.1:80 ??? D: 10.0.0.1:80 10.0.0.1 10.0.0.2
socket()
bind(*, 80)
listen(5)
:80
??? D: :80
connect( ,80)
socket()
S: :3045 D: :80
S: :80 D: :3045
accept()
S: :80 D: :512
S: :80 D: :2047
S: :2047 D: :80
S: :512
bind( ,512)
S: :512 D: :80
connect( ,80)
CS 3214 Fall 2011

24. Utility Functions in_addr_t inet_addr(const char *cp);
Those shown in gray are
IPv4 specific and thus
deprecated.
in_addr_t inet_addr(const char *cp);
char *inet_ntoa(struct in_addr in);
int gethostname(char *name, size_t len);
int getpeername(int s, struct sockaddr *name, socklen_t *namelen);
int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
int getsockopt(int s, int level, int optname, void *optval, socklen_t *optlen);
int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);
struct hostent *gethostbyname(const char *name);
struct hostent *gethostbyaddr(const char *addr, int len, int type);
int getaddrinfo(const char *node, const char *service, const struct addrinfo *hints, struct addrinfo **res);
void freeaddrinfo(struct addrinfo *res);
CS 3214 Fall 2011

25. Protocol Independent Socket Programming
Client + server code should be unaware of which version of IP is used
Use getaddrinfo() to obtain information about suitable address family and addresses
For servers to bind to (IPv4, or IPv6, or both)
For clients to connect to (based on DNS name or specified address notation); based on RFC 3484 ordering
Use getnameinfo() to transform addresses in printable form
See for details
CS 3214 Fall 2011

26. Java Binding Does not expose byte order
gethostbyname()/getaddrinfo() is hidden (use a “String” as a hostname to get default 1st IP address)
Does not expose bind/listen directly
Use different types for different sockets:
DatagramSocket, Socket, ServerSocket
Does not expose universal file descriptor
Hides IPv4/IPv6 behind InetAddress superclass
CS 3214 Fall 2011

27. Common Pitfalls (1) Network vs. Host Byte order
Network order is big endian, most-significant byte first
Host order may be either big or little: little endian on x86
Use ntohs(), ntohl(), htons(), htonl() to convert 16-bit (“short”) and 32-bit (“long”) values portably
Never convert addresses/ports in sockaddr_in structures in place
Not as much an issue in languages that hide data representation (e.g., Java)
CS 3214 Fall 2011

28. int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
Common Pitfalls (2)
Pay attention to “length” parameters
Example
namelen here is not OUT, its INOUT
aka value-result
You know what socket it is, the OS doesn’t!
Always check return codes!
int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
CS 3214 Fall 2011

29. Common Pitfalls (3) What is wrong with this code?
struct sockaddr_in server1addr;
struct sockaddr_in server2addr;
/* not shown: initialize server1addr, server2addr */
printf(“using server 1 at %s and server 2 at %s\n”,
inet_ntoa(serveraddr1.sin_addr),
inet_ntoa(serveraddr2.sin_addr));
Beware of statically allocated buffers! Don’t use in new code!
Use alternatives where available: inet_ntop, getaddrinfo, etc.
CS 3214 Fall 2011