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[]=“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.

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 externalstorage (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 << hptr->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 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

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;

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:” << pptr->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);

ProtocolFamily

Service Only one protocoloffers 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 connecting!

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

Client ServerOS may buffer!

write(s,”Hi”..);write(s,”To”..);write(s,”You”..);

os buffer

HiToYou

HiToYou

Reader does not see “write”blocks, only a

stream.

Reading from a TCP socket

1. Read and write fixed sized blocks2. Look for terminating symbols3. Send SIZE fields at the head of each block

Frame formatting strategies

Always do reading in loops untilthe 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 allowed1 - no more output allowed2 - closed in both directions

UDP client

Allocate socket for this protocol SOCK_DGRAM for type UDP for protocol

Get local IP/portResolve 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.