- Simpler than servers - one request-response, non privileged access
- Not simpler - recovery from failures
- Repeatedly
- Locate the server.
- Connect to the server.
- Repeatedly
- Create and send a request.
- Wait for the reply (or not).
- Receive and process the reply.
- Tear-down the connection.
- Where's that server - well known or discovered - flexibility (no
hardwiring addresses), cost (don't broadcast over wans), anycasting
(property based choice)
- There's a similar problem with ports -
getservbyname(); but what
are the service names; /etc/services, ypcat services,
rfc 1700
- What address format - domain names or ip addresses; only ip addresses
exist
- Domain name translation - given a domain name, get the associated ip
address;
gethostbyname()
- Don't forget the byte ordering
- Protocol numbering -
getprotobyname(); I've never used this
- Create a socket.
- Find a local port number - not usually necessary; let the operating
system pick
- Picking the ip address - multi-homed hosts; a good choice requires
routing information; let the os do it
- Connect to the server - resolve the local endpoint if necessary
- Communicate -
send() and recv() are like read() and
write() except for an options argument; oob data
- Remember when reading server data - tcp doesn't respect message
boundaries; keep reading until you've got enough
- Close - don't forget duplex traffic
- About the same as a byte-stream server.
- Connecting to the server isn't necessary, but convenient - can use
read() and write(); otherwise, must give the server endpoint
- Data transfer is message oriented - easier
- Partial closing isn't as useful - no shut-down handshake
- 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 4 February 2003.