[ 1 ] ------------------------------------------------------------------------ Introduction to Socket Programming - enough to get started - not covering IP - not covering ioctl or system calls in C - not covering HTML (needed for contest) [ 2 ] ------------------------------------------------------------------------ Overview - Phone Analogy - a nice way to think of sockets - Sockets API - introduce the 5 main socket sys calls - Net Byte Order - explain ordering of bytes in a network stream - Naming Serv - talk about how to conv name <-> IP - Client & Server - how to write a simple net program - Data Tx - different data transfer methods - Socket ioctl - configuration of a socket - References - lots of links [ 3 ] ------------------------------------------------------------------------ The Phone Analogy - it would seem like sockets were modeled after the phone network - phone == socket - phone number/extension == IP/port - 411 == DNS - caller == client - recipient == server - mostly true about TCP, connection oriented - UDP is more like mail, no connection, just datagrams [ 4 ] ------------------------------------------------------------------------ ...The Phone Analogy - get a phone - get a phone - select outgoing line - select incoming line - dial the number - turn on the ringer - talk - pickup - hang up - talk - hangup - UDP... a far less used protocol - not too much coverage in this talk - unless specified all sockets below will be TCP sockets - UDP is less like a phone network and more like the postal service - put the stamp on the datagram, put it in the mailbox, and hope it gets there [ 5 ] ------------------------------------------------------------------------ The Sockets API - socket - go to buy a phone and plug it in - create a steam socket or a datagram socket - not just an ip socket - mandatory by both clients and server - bind - the first thing you have to do is configure your port (optional) - you can also specify the phone number to use if you have >1 line - cli/srv passes a struct sockaddr_t to specify local IP+port - listen - server must start listening for connections - specify the queue of incoming calls (put on hold) - accept - server picks up the call - new socket is created; old used for new calls; new used for communication - server is passed caller's credentials (struct sockaddr_in) - connect - client makes a call to a server - client passes a struct sockaddr_t to specify where to call [ 6 ] ------------------------------------------------------------------------ Network Byte Order - network byte ordering is very important - consider a 16-bit value; there are two ways to store this value at address A; one way is to store the MSB at A and LSB at A+1; the other is the reverse val = 0x1234 A = &val *(A) = 0x34 *A = 0x12 *(A+1) = 0x12 *(A+1) = 0x34 - the internet protocols use big-endian - it is very common to see hton* functions when filling/reading structures which are passed to the socket API functions [ 7 ] ------------------------------------------------------------------------ Naming Services - well written net progs will take a hostname from the user and convert it to an IP address - similary an IP from an accept should be given to user after a reverse lookup is made - see man pages for more info [ 8 ] ------------------------------------------------------------------------ ...Naming Services - inet_*to* calls allow to convert the "dotted decimal" into an internet address structure - get*info calls hide protocol dependencies; evolved in Posix.1g - see man pages for more info [ 9 ] ------------------------------------------------------------------------ The Client - this is what a simple client needs to do... - create a socket - optionally select a local IP and port (bind call not shown) - connect to a remote scok_addr - ... == communicate via read() / write() - finally close the socket; under UNIX this is done when process exits [ 10 ] ----------------------------------------------------------------------- The Server - this is what a simple server needs to do... - create a socket - bind to a local port (optionally address) - start listening for connections - set back log queue of un accepted connections - for each client that comes in accept that client - communicate and terminate the client - finally close the server socket; any client sockets opened are uneffected by this - one problem with this is that it can handle only one client at a time and, because of the 5 in listen(), only 5 other are held on while the first communicates [ 11 ] ----------------------------------------------------------------------- ...The Server (multiple concurent clients) - threaded approach for multi clients [ 12 ] ----------------------------------------------------------------------- ...The Server (select) - not meant to compile - also incomplete - fd_set is an array of bits telling select what to look at - on rturn the rfds can be tested with FD_ISSET to see if the event trigered - 3 event types: read, write, exception - select does not scale very well - for more sockets it's better to use poll - for more yet it's better to use async io (Ben LaHaise) [ 13 ] ----------------------------------------------------------------------- Data Transfer - datagram; UDP only - can specify where to send for a non-connected DATAGRAM socket - can test to see where a packet came from - useful for UDP and multicast - unbuffered; any - very clean interface using read() and write() - very easy to use common code that can use serial, parallel, or net - buffered stream transfer - not very useful as TCP already does streams; UDP is lossy and a lossy stream is just like lying to oneself [ 14 ] ----------------------------------------------------------------------- Socket I/O Control - sockets have a lot that can be configured and these functions do the job