Client Design

1. Client Design

2. Issues • Server Identification • Setting up a socket on client side • TCP • Reading and writing with a socket • Closing a socket • UDP • Reading and writing with a socket • Closing a socket

3. Server Identification • What is the machine name of the server? • What is the IP address of that machine? • What is the port number of the service? • What is the protocol number (integer) of the protocol you wish to use?

4. Identifying the machine name • Hard code name into the code • name OR ip address • Use command-line for user specification • Store the data on disk • Use a protocol server • DNS

5. Hard coding the name • Typical beginner approach • char servername[]=“america3.pcs.cnu.edu” • char servername[]=“137.155.2.20” • No flexibility for • moving server • using an alternate server while testing upgrades • multiple versions of the server • Using a name does allow for some flexibility as we will see later.

6. Server name from command-line • e.g. serverapp america3.pcs.cnu.edu • Window OS should provide a means for user to specify arguments. Can you find it in W95/98? int main(int argc, char argv[][]) //other ways to define {… if (argc>1) cout << “first parameter is “ << argv[1] << endl; }

7. Storing the name on externalstorage (disk) • No need to change application change configuration • Typical means of parameterizing an application • Others • Windows • ini files • registry • Unix • system variables

8. Use a protocol server • Local server: …e.g. • Implement a local server at a known port which serves all requests for your network • (that’s hard coded …..) • Have THE server also respond to requests for address. • Use broadcast IP and the port number of the service • assumes ONE per network • does not scale past the LAN (IP address) well • Nonlocal server • broadcast does not work

9. DNS • Use a well known server name • e.g. • ftp.pcs.cnu.edu • ftp.cnu.edu • Let DNS provide the service • Extends beyond the realm of the LAN • Easy to modify actual server location and update all clients which bother to check • Does not do versions • uses gethostbyname()

10. What is the server IP? • Assuming the server machine name is known, use DNS • DNS client IS your application. • Using gethostbyname()is accessing code linked into your application • machine must be configured to access a dns server, but usually done be administrator • A name can map to a number of IP addresses if multiple interfaces (router)

11. DNS via c/c++ struct hostent{ char FAR* h_name; // official host name char FAR* FAR* h_aliases; // other aliases short h_addrtype;// address type short h_length; // address length char FAR* FAR* h_addr_list// list of addresses }; #define h_addr h_addr_list[0]; struct hostent *hptr; char *hostname=“america3.pcs.cnu.edu”; if (hptr = gethostbyname ( hostname ) ) { cout << hptr->h_addr << endl; else cout << “IP address not found” << endl;

12. Identifying the port number • Port number selection is tricky • Some port numbers reserved by Internet • Some port numbers reserved by OS • You can use these is “root” sets it up • You choose a port number >2000 • You compete with all other apps on the machine • No pecking order after OS numbers

13. Identifying the port numbergetservbyname • Service is not JUST a port number • port and protocol … recall the defn of a socket • many TCP services also on UDP • DEFINED ON YOUR MACHINE • in unix .. /etc/services • you must keep services definition accurate • like storing on a local disk for server name

14. getservbyname() struct servent { char FAR* s_name; // official service name char FAR* FAR* s_aliases;// other aliases short s_port; // port for this service char FAR* s_proto; // protocol } struct servent *sptr; if (sptr = getservbyname( “yourservice”, “tcp”) ) { cout <<“Running on port “<< sptr->s_port <<endl; else cout <<“Service information not available” << endl;

15. What is the protocol number? • Not frequently used, more often hardcoded. • Used subsequently in socket() call. • Like service, locally defined • in unix in /etc/protocols • use getprotobyname()

16. getprotobyname() struct protoent { char FAR* p_name; // official name char FAR* FAR* p_aliases; // alias list short p_proto; // official number } struct protoent *pptr*; char pname[]=“tcp”; if (pptr = getprotobyname (pname) ) { cout << “Protocol:”<<pname<<“ Number:” << pptr->p_proto << end; else cout << “No definition of protocol” << endl;

17. TCP vs UDP issues • Writing client side applications with these two protocols are different • NOT a simple code change to go from one form to another • TCP - connection oriented expects both ends to be defined but “dials” first • UDP - connectionless requires two ends too but does not “dial” before sending

18. TCP client • Allocate socket for this protocol • Get local IP/port • Resolve server IP/port • Connecting • Reading and writing • Closing

19. Allocating a TCP socket • Mostly hardcoded • Must define • protocol family • service • protocol (not required if only one protocol in the family provides that service) s = socket(PF_INET, SOCK_STREAM, 0); Protocol Family Service Only one protocol offers this service in TCP/IP

20. Getting a local IP/port • Client side port numbers are not fixed • TCP randomly assigns you an available port number. • Good because it avoids conflicts and server does not need it ahead of time due to direction of the connection • returned port is in the updated socket parameter • IP address for host is a no-brainer because the machine only has ONE and TCP looks that up for you too when connecting!

21. Getting a local IP/port (ctd) • For a machine with multiple IPs tricky but not a death sentence if you do it wrong. • Issue: try to have data from client-server and server->client travelling same direction • Not completely critical Route 1 Route 2

22. Writing into a TCP socket Client OS may buffer! Server write(s,”Hi”..); write(s,”To”..); write(s,”You”..); HiToYou HiToYou Reader does not see “write” blocks, only a stream. os buffer

23. Reading from a TCP socket Frame formatting strategies 1. Read and write fixed sized blocks 2. Look for terminating symbols 3. Send SIZE fields at the head of each block Always do reading in loops until the end of the logical frame appears according to the formatting strategy above

24. Reading TCP sockets in a loop Read and write fixed sized blocks n = recv(socket, bufptr, buflen, 0) while (n!= SOCKET_ERROR && n!=0) { bufptr +=n; buflen -= n; n = recv(s, bufptr, buflen, 0); } Terminating framing techniques are tricky. Fixed size simply require reading ONE byte then using the above strategy.

25. Closing a socket • Need to use partial close. • Communication is 2-way. Just because you close in one direction does not imply closing in the reverse direction • Use shutdown() to indicate closing in a particular direction. Shutdown(socket, direction); 0 - no more input allowed 1 - no more output allowed 2 - closed in both directions

26. UDP client • Allocate socket for this protocol • SOCK_DGRAM for type • UDP for protocol • Get local IP/port • Resolve server IP/port • (Specify the server) * • Reading and writing * • Closing

27. Connecting with the server • There really is NO connecting • If you use the connect() call • lets the client socket software know endpoint • NO connection is done, server may not even exist! • If connect() used, follow with send() and recv() • Else sendto() and recvfrom() • recvfrom() does not tell who from, it learns who from

28. Connecting with the server (ctd) • UDP (continued) • recall datagrams are sent and received as blocks • make it as a whole or none • reading is simple but not support for correction • recv() also truncates if buffer is not long enough • closesocket() to end but not sent to server. • shutdown() works too, but nothing sent to server.