CS162B: IPv4 Socketing Jacob T. Chan

Socketing in the Real World  Most computer games are multiplayer in nature or have multiplayer components  DotA, LoL, HoN, WoW and all those acronym-related games  There are some useful applications that do use socketing too  Garena, Yahoo Messenger (if it still exists)

Sockets  Header files  #include  #include //VERY important  #include  Not required anymore to link any library

Accessing Sockets  Sockets are just like files  They are identified using file descriptors, which are just pointers, which are just ints  Applies to both client and server  Sockets allow data to be exchanged between applications that may be running on different computers connected by a network  Both server and client need a socket! Otherwise, there will be no connection  The server must then bind its socket to a well-known address which the client can locate in case of connection to server

int socket(int domain, int type, int protocol)  Domain specifies communication domain  Value is usually AF_INET (since we will use IPv4)  Type can either be two values: SOCK_STREAM or SOCK_DGRAM  Difference: connectivity. TCP or UDP  Illustration: mailbox vs direct  There are other values available, which you can research on your own, but these two are popular  Protocol is the protocol to be used in the socket  Value is usually 0 because we use SOCK_STREAM and SOCK_DGRAM

Setting Up Connections  Client Side: struct sockaddr_in destination; struct hostent *host; destination.sin_family = AF_INET; destination.sin_port = htons(DESTINATION_PORT); host = gethostbyname(hostname); //hostname = IP address or host name  Returns NULL on error destination.sin_addr.s_addr = inet_addr(inet_ntoa(*((struct in_addr *)host->h_addr)));  inet_addr returns -1 on error

Setting Up Connections  Server Side: struct sockaddr_in my_addr; my_addr.sin_family = AF_INET; my_addr.sin_port = htons(LISTENING_PORT);  Setting LISTENING_PORT to 0 means that any port can be chosen by the system, but the dilemma is that how is the client supposed to know which port is being used?  LISTENING_PORT for server is equal to DESTINATION_PORT of client my_addr.sin_addr.s_addr = INADDR_ANY;  INADDR_ANY means that your local IP address will be used

So far…  Server and client are just prepared to connect to one another  What we did so far is to provide necessary information for establishing a connection to the network  Client can now make connection requests  Server can now listen to requests

Client: int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)  Returns -1 on eror  If successful, client connects to the server and can now read() and write(), or send() and recv() data  Read-write is the standard with the file descriptors  Send-recv system calls are for socket-specific I/O system calls  They provide additional socket-specific functionality  NOTE: Ports less than 1024 are RESERVED, so make sure that you choose from ports 1024 – to be safe

Server: int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)  Fills in information regarding IP address and port number  Informs system that the port will be used by socket  Error will occur if another program is already using the port  Returns -1 on errror  sockfd is open file descriptor corresponding to the socket  sockaddr holds address information  addrlen specifies the size of the structure address

Server: int listen(int sockfd, int backlog)  Marks stream socket referred to by file descriptor as passive  Passive sockets ALLOW incoming connections  Backlog specifies the number of connection requests that can be placed on queue if server is currently busy  Usually  Tells socket to begin listening for connections  Returns -1 on error

Accepting Connections struct sockaddr_in clientAddress; int size = sizeof clientAddress; int clientfd; clientfd = accept(sockfd, (struct sockaddr *)&clientAddress, &size);  accept() will take the first connection in the queue prepared by listen() and create a dedicated socket for that connection. If the queue is empty, accept() will BLOCK until a connection is present, NOT listen()  If the server still has to do something while waiting for connections, you will need to use concurrent processes or use the select() or poll() function, which is not covered here.  accept() is the one that blocks, NOT listen()!  The clientAddress will be filled ONLY during accept() is called and after there is a listen() called before it

Sending Data int send (int fd, char *buffer, int size, int flag)  fd is your file descriptor (for server, you need the client’s file descriptor, and for client, you need the socket file descriptor)  buffer is a pointer to whatever you need to send  Arrays are pointers, so you can make it work even if you declared buffer[N}  size is the buffer size in BYTES  flag is the set flags, which is usually 0 (to note of no flags)  Returns -1 on error

Sending Data  BUT, send() returns the number of bytes sent out  Which can be less than the number of bytes you told it to send  This case usually happens if your data is too big, so you send the rest later  Solution: loop send()  But no need to do this if you don’t really need or want to

Receiving Data int recv(int fd, char *buffer, int size, int flag)  fd is your file descriptor (for server, you need the client’s file descriptor, and for client, you need the socket file descriptor)  buffer is the character array that recv() will write to  size is the true size of the buffer in BYTES  flag is the flag set, which is usually 0 (to indicate no flags)  Returns -1 on error

Receiving Data  BUT, calling recv() can receive contents of more than 1 call of send()  Which implies that most programsthat send() variable-length data must be red separately  Solution: send a fixed-length data before actually sending X: sprintf(limiter, "%08d\0", strlen(x)); send(sockfd, limiter, 8, 0); send(sockfd, x, strlen(x), 0); printf("Sent message: %s (%d chars)\n", x, strlen(x)-1);

Closing everything  Close all socket descriptors  So that the socket can be reused by other programs  Otherwise, not cleaning will result into the unreusability of the socket  Rebooting is the only way to restore that socket!  Client close(sockfd);  Server close(sockfd); close(clientfd);

Lab 11: server.c and client.c  Create two programs server.c and client.c that does the following:  The server should accept ANY number of connections from multiple clients.  When a client connects to the server, the server should be able to spawn a new process that handles a connection with this client  The server, once connected to a client, should be able to continue to listen for new incoming requests  As for the client side, it should display the line “input string to search: “ on the console. Each time a query string is provided, the client sends this to the server  The server then searches for the word in the text file. If the phrase is found, the server should return the lines with that phrase to the client  Otherwise, return a “NOT FOUND: ”  The client will continue looping until the phrase “/EXIT” is encountered  Guaranteed that in the text file, there is no string “/EXIT”

Lab 11: server.c and client.c  Create two programs server.c and client.c that does the following:  Upon exiting, the client should inform the server that it is disconnecting. But that does not mean server should already exit.  You do this so that it will tell the process on the server side to stop processing that client.  The server will run a file, which will be its basis of searching  The server and client need not to run on the same machine, though they need to be connected to the same IPv4 network.  Server and client will run as follows:./server./client  NOTE: This works like a remote search bar.

Lab 11: server.c and client.c  Of course, errors should still be handled (like errors on wrong arguments, wrong IP address format, and other connection function-related errors)  Legalities  Certificate of Authorship, along with your server.c and client.c programs  Filename: CS162B_Lab11_ _ _.tar  Deadline: Next week midnight  Tuesday for Section A  Thursday for Section B