Cs162b ipv4 socketing
This presentation is the property of its rightful owner.
Sponsored Links
1 / 20

CS162B: IPv4 Socketing PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

CS162B: IPv4 Socketing

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Cs162b ipv4 socketing

CS162B: IPv4 Socketing

Jacob T. Chan

Socketing in the real world

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)



  • Header files

    • #include <sys/types.h>

    • #include <sys/socket.h> //VERY important

    • #include <arpa/inet..h>

    • #include <netdb.h>

  • Not required anymore to link any library

Accessing sockets

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

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

Setting Up Connections

  • Client Side:

    structsockaddr_in destination;

    structhostent *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(*((structin_addr *)host->h_addr)));

    • inet_addrreturns -1 on error

Setting up connections1

Setting Up Connections

  • Server Side:


    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

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

Client: int connect(intsockfd, conststructsockaddr *addr, socklen_taddrlen)

  • 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 – 65536 to be safe

Server int bind int sockfd const struct sockaddr addr socklen t addrlen

Server: int bind(intsockfd, conststructsockaddr *addr, socklen_taddrlen)

  • 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

Server: int listen(intsockfd, 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 10-20

  • Tells socket to begin listening for connections

  • Returns -1 on error

Accepting connections

Accepting Connections


int size = sizeofclientAddress;


clientfd= accept(sockfd, (structsockaddr*)&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

Sending Data

int send (intfd, 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 data1

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

Receiving Data

intrecv(intfd, char *buffer, int size, int flag)

  • fdis 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 data1

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

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


  • Server



Lab 11 server c and client c

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: <string _to_be_searched>”

    • 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 c1

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 <port> <file>

      ./client <server_ip> <port>

    • NOTE: This works like a remote search bar.

Lab 11 server c and client c2

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_<Section>_<Surname>_<ID_Number>.tar

    • Deadline: Next weekmidnight

      • Tuesday for Section A

      • Thursday for Section B

  • Login