5. Address binding
Local addr.port Remote addr.port Description
*.port *.* All local interfaces
laddr.lport *.* Specific local interface
laddr.lport raddr.rport One client
6. Server init
getaddrinfo() - convert hostname to ip address
socket() - create a socket
bind() - associate with a port to listen on
listen() - marks the socket referred as a passive socket and setups the number of
pending connections
accept() - block waiting on a new connection
getnameinfo() - get host and port as strings
7. Client init
getaddrinfo() - convert hostname to ip address
socket() - create a socket
connect() - connect to a remote port (optionally)
8. Communication over TCP sockets
send() - returns number of sent bytes or -1
recv() - returns number of received bytes or 0 (closed conn on a remote side) or -1
9. Communication over UDP sockets
sendto() - returns number of sent bytes or -1
recvfrom() - returns number of received bytes or -1
OR, if connect() was called, use:
send() - returns number of sent bytes or -1
recv() - returns number of received bytes or -1
10. Closing socket
close() - close and free
shutdown() - close not free with option:
SHUT_RD
SHUT_RDWR
SHUT_WR
13. Multiplexing server
getaddrinfo() - convert hostname to ip address
socket() - create a socket
bind() - associate with a port to listen on
listen() - marks the socket referred as a passive socket and setups the number of
pending connections
select/poll/epoll/kqueue - blocks waiting on multiple connections events
getnameinfo() - get host and port as strings
14. Multiplexing using select
select(num, readfds, writefds, exceptfds, timeout)
1. Manipulate bitmaps of max size 1024 bits using macros FD_SET, FD_CLR,
FD_ISSET, FD_ZERO
2. Select returns modifies bitmaps thus applications should refill the interest sets
for every call.
3. Thus both application and kernel have to scan entire bitmaps on each call to
figure out interest sets and the result sets.
4. Moreover kernel iterates over interest set to find out which file descriptor is
ready.
15. Multiplexing using poll
Cons
App and kernel still have to scan to
figure out interest and result fd
sets
Kernel still have to check which fd
of interest are ready as far as
there is no state saved.
API
poll(struct pollfd *fds, int nfds, int timeout)
Pros
Relies on array of file descriptors
instead of bitmaps. Thus no 1024
limit.
Interest and result sets are
separated, so app does not need
to update it each time
16. Multiplexing using epoll in Linux
API
int epoll_create(int size) - Create
interest set
int epoll_ctl(int epfd, int op, int fd, struct
epoll_event *event) - Add fd
int epoll_wait(int epfd, struct epoll_event
*events, int maxevents, int timeout) -
Wait
Two modes: level triggered and edge
triggered
Pros
Stateful, no scan on each time is required
Multiple interest sets in one process
Cons
Can not add multiple descriptors at once
17. Multiplexing using kqueue in FreeBSD
API
int kqueue(void);
int kevent(int kq, const struct kevent
*changelist, int nchanges,
struct kevent *eventlist, int nevents,
const struct timespec *timeout);
Pros
Stateful, no scan on each time is
required
Multiple interest sets in one process
Can add multiple descriptors at once
Can work not only for sockets, but for
files, timers, signals, ...
19. References
Using network sockets
Scalable Event Multiplexing: epoll vs. kqueue
The C10K problem
Re: Linux's implementation of poll() not scalable?
How to use epoll? A complete example in C