1. simpler than servers - one request-response, non privileged access

2. not simpler - recovery from failures

3. where's that server - well known or discovered - flexibility (no hardwiring addresses), cost (don't broadcast over wans), anycasting (property based choice)

4. what address format - domain names or ip addresses; only ip addresses exist

5. domain name translation - given a domain name, get the associated ip address; gethostbyname()

6. there's a similar problem with ports - getservbyname(); but what are the service names; /etc/services, ypcat services, rfc 1700

7. don't forget the byte ordering

8. protocol numbering - getprotobyname(); I've never used this

9. the client algorithm for tcp

   1. create a socket

   2. find a local port number - not usually necessary; let the operating system pick

   3. picking the ip address - multi-homed hosts; a good choice requires routing information; let the os do it

   4. connect to the server - resolve the local endpoint if necessary

   5. communicate - send() and recv() are like read() and write() except for an options argument; oob data

   6. and remember when reading server data - tcp doesn't respect message boundaries; keep reading until you've got enough

   7. close - don't forget duplex traffic

10. the client algorithm for udp

    1. about the same as tcp

    2. connecting to the server isn't necessary, but convenient - can use read() and write(); otherwise, must give the server endpoint

    3. data transfer is message oriented - easier

    4. partial closing isn't as useful - no shut-down handshake

    5. however, don't forget to deal with best effort delivery - lost packets, corrupted packets, out of order packets, duplicated packets; this is hard to do well.

This page last modified on 1 February 2001.