Client Design

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

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?

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

Hard coding the name Typical beginner approach char servername[]=“america3.pcs.cnu.edu” char servername[]=“ ” 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.

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; }

Storing the name on external storage (disk) No need to change application change configuration Typical means of parameterizing an application Others –Windows ini files registry –Unix system variables

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

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()

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)

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 h_addr << endl; else cout << “IP address not found” << endl;

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

Identifying the port number getservbyname 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

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 s_port <<endl; else cout <<“Service information not available” << endl;

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()

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:” p_proto << end; else cout << “No definition of protocol” << endl;

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

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

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 ServiceOnly one protocol offers this service in TCP/IP

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 connect ing!

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

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

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

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

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

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

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

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.