Computer networks -- 2008-2009 -- info.uvt.ro/Course 2

From Wikiversity

Quick links: front; agenda; courses 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13; examination.

Important! Please note that the current work serves mainly as general guidance and discussion topics, and is by no means the reference material for the course. For further information please consult the dedicated section.

Network architectures[edit]

(from a programming perspective)

  • concepts:
    agent / actor;
    role;
    heterogeneous vs homogeneous;
  • architectures:
    client-server
    • there are two main roles client and server;
    • usually there is only one server, and multiple clients; (in the case when there are multiple servers, they are equivalent;)
    • the client's responsibilities are (in general):
      • initiating the communication with the server;
      • (optional) identifying itself to the server;
      • sending a request;
      • waiting for the response;
      • maybe continue with the previous two steps;
    • the server's responsibilities are (in general):
      • waiting for communications from the client;
      • (optional) identifying itself to the client;
      • (optional) authenticating the client;
      • (optional) authorizing the client;
      • receiving the request;
      • fulfilling the request;
      • replying with a response;
      • maybe continuing with the previous three steps;
    multitier
    • like the client-server architecture but in this case there is more than 2 levels of roles;
    • each level (tier) waits for requests from the upper one, and generates new requests for the one below;
    peer-to-peer (as an opposite to the client-server model)
    • all the agents are equal in roles;
    • one agent could act as both a client or a server;
    distributed
    • (by "distributed" we are referring to "distributed computing"; not to the fact that the agents are "distributed" (spread) as location;)
    • usually all the agents play the same role;
    • all the agents cooperate to solve a common problem;
    • there is a certain level of common trust between the agents;
    • usually all the machines are under the same administrative authority; (maybe part of a cluster or a set of clusters;)
    • usually all the agents represent an homogeneous environment;
    peer-to-peer (as a variant of distributed computing)
    • it resembles the distributed computing model, but with important differences;
    • the agent owners are independent of each other; (usually they are owned by individual persons;)
    • there is no great deal of trust between the agents;
    • the environment is an heterogeneous one;
    • the relation between peers is short lived;
  • comparisons from different points of view:
    maintenance;
    cost;
    security;
    load;
    scalability;
    resilience;

Brief (crash) TCP/IP introduction[edit]

  • what is the Internet?
  • the Internet protocol suite is the "system" by which data is sent from one computer to another on the Internet;
  • each computer (known as a host) on the Internet has at least one IP address that uniquely identifies it from all other hosts on the Internet;
  • each computer is connected to a network through an extension device called network interface;
  • usually each network interface has one or multiple IP addresses attached;
  • the protocol suite is composed of several (layered) protocols:
    IP (Internet Protocol)
    • a connectionless protocol, which means that there is no continuing connection between the end points that are communicating;
    • there are several other protocols used together with (more exactly layered over) IP in order to provide additional features, the most common ones are below;
    TCP (Transfer Control Protocol)
    • provides reliable, in-order delivery of a stream of bytes;
    • it manages individual conversations between servers and clients;
    UDP (User Datagram Protocol)
    • enables hosts to send short messages, named datagrams, between them;
    • it does not guarantee reliability or ordering;

Network addressing[edit]

(from a programming perspective)

  • host addressing:
    host name
    • human readable machine (unique) identifier;
    • example: www.google.com
    IP address
    • numerical machine (unique) identifier;
    • example: 194.102.62.1;
  • service addressing:
    port number
    numerical service identifier on a given machine;

Sockets[edit]

  • a socket is an abstraction for a communication channel end-point, that allows data exchange between peers;
  • a socket could be used for either network communication or local inter-process communication;
  • to work with sockets we need an adequate API:
    • the socket API was initially introduced by Berkeley university in 1983, long before the Internet -- TCP/IP -- was born;
    • the API was initially only available for C programming language;
    • it was quickly adopted as libraries for almost all languages;
    • today it is a "de facto" standard for network application interfaces;
  • (generic) operations and life-cycle:
    creation
    the socket is created and is ready to be used;
    setup
    before any other operation we can (optionally) initialize certain parameters;
    data exchange;
    destruction
    releasing all the resources committed to it, and no other operation is allowed after this;
  • classification:
    • by underlying (network) protocol:
      • TCP or UDP;
      • Unix
      • IPX
      • X.25
      • ATM
      • raw
    • by protocol characteristics:
      • connection-oriented (like TCP) or connection-less (like UDP);
      • stream (like TCP) or datagram (like UDP);
      • reliable (like TCP) or unreliable (like UDP);
  • concerns:
    byte-ordering
  • operation types:
    synchronous
    blocking;
    non-blocking;
    asynchronous;

Addressing sockets[edit]

  • in what follows we shall discuss only about TCP or UDP sockets;
  • socket addresses:
    local socket address
    • each socket has one;
    • used to identify the local communication end-point;
    • represents the source of the outbound data;
    • represents the destination of inbound data;
    remote socket address
    • available only for connection-oriented sockets;
    • used to identify the remote communication end-point;
    • represents the destination of outbound data;
    • represents the source of inbound data;
  • the address of a socket is composed of:
    IP address
    port
  • we can use host names by translating them into IP addresses;

Snippet examples[edit]

  • creating an IP address from raw bytes:
byte[] ipAddressAsBytes = new byte [] {(byte) 192, (byte) 168, (byte) 0, (byte) 1};
InetAddress ipAddress = InetAddress.getByAddress (ipAddressAsBytes);
  • creating (parsing) an IP address from a string (that contains the dotted representation of a valid IP address):
String ipAddressAsString = "192.168.0.1";
InetAddress ipAddress = InetAddress.getByName (ipAddressAsString);
  • creating (resolving) an IP address from a string representing a valid host name:
String hostName = "localhost";
InetAddress ipAddress = InetAddress.getByName (hostName);
  • creating (parsing) a port from a string (that contains a number):
String portAsString = "80";
int port = Integer.parseInt (portAsString);
  • creating a socket address from an IP address and a port:
InetAddress ipAddress = ...;
int port = ...;
SocketAddress socketAddress = new InetSocketAddress (ipAddress, port);
  • creating a socket address directly from a host name and a port:
String hostName = ...;
int port = ...;
SocketAddress socketAddress = new InetSocketAddress (hostName, port);

Complete examples[edit]

  • Interfaces:
    • displays the local address (usually localhost);
    • iterates through all the available network interfaces;
    • iterates through all the IP addresses attached to each network interface;
  • Resolution
    • tries to resolve a couple of host names into IP addresses;
    • for each host name it displays the available IP addresses;
    • for each IP address (belonging to each host name) it displays the reverse name;
    • for each host name it tries to determine if it is on-line or not;

Java API[edit]

UDP sockets[edit]

  • UDP sockets are mostly used in the client-server model;
  • as a consequence we have two categories of applications:
    clients
    • applications that usually run on the users computer -- a workstation, desktop, laptop or even smart-phone and PDAs;
    • these applications connect to a specific server, send requests, and wait for responses;
    • they are required to know in advance the exact IP address and port of the server -- the destination socket address;
    servers
    • applications that usually run on dedicated hardware and software -- on a server machine;
    • these applications offer a well defined service to any client that communicates with it;
    • it has to listen on a specific IP address and port -- this is the server's local socket address;

Life-cycle (for both client and server side)[edit]

  • operations:
    creation
    the socket object is created;
    binding
    the local socket address is established (IP address and port);
    data exchange
    we shall see further what data exchange implies;
    destruction
    the socket object is destroyed, and no longer used;

Data exchange[edit]

  • sending
    datagram creation
    we create a datagram object for which we establish:
    • the data buffer -- what we want to send;
    • the destination socket address -- where do we want to send the datagram; this is composed of an IP and port of the other entity;
    datagram sending
    we actually send the datagram over the network to the specified destination;
  • receiving
    datagram creation
    we create a datagram object for which we establish:
    • the buffer -- where we want to receive the data;
    waiting
    we wait for datagrams, and when one arrives we obtain it;
    decoding
    • we must obtain the datagram length, in order to know how much of the buffer has been written;
    • we may also obtain the sender's socket address;
  • observations:
    • from the previous steps we can see that the data exchange could be done with multiple entities, thus one client could speak with more than one server (or one server with multiple clients) by using the same socket (something which in the case of TCP sockets is not possible);
    • in the case of UDP sockets we must prepare in advance the buffer where we want to receive the data, and in the case the buffer is to small to hold the entire received datagram, usually an error will be raised, and we can retry with a greater buffer;

"Connected" UDP sockets[edit]

  • the Java API allows us to have "connected" UDP sockets;
  • the life-cycle difference is in the fact that we introduce another step -- the connection step -- between the binding and the data exchange;
  • we then can remove the remote socket address setup step for outgoing datagrams;
  • this does not mean that we shall use a connection-oriented UDP socket, this is just an Java API facility which allows us to ignore the remote socket address when sending, provided that we communicate with only one server, thus no packet is sent during the connection step, and on the wire there is no difference between the two variants;
  • this style of UDP sockets is discouraged as it leads to bad habits;

Snippet examples[edit]

  • creating and binding the socket on any local available IP address and on a random port:
DatagramSocket socket = new DatagramSocket ();
  • creating and binding the socket on a specific socket address:
SocketAddress socketAddress = ...;
DatagramSocket socket = new DatagramSocket (socketAddress);
  • sending a datagram:
    • preparing the datagram backig buffer:
int datagramBufferSize = 1024;
byte[] datagramBuffer = new byte [datagramBufferSize];
/* fill the buffer with relevant data starting from an offset (usually 0) */
int datagramBufferOffset = 0; // or the offset inside the buffer from which you have written
int datagramBufferUsed = ...; // the amount of data that you have copied inside the buffer
/* obviously the following conditions must be met:
   * 0 <= datagramBufferOffset < datagramBufferSize
   * 0 < datagramBufferUsed <= datagramBufferSize
   * (or sub-summing both) 0 < datagramBufferOffset + datagramBufferUsed <= datagramBufferSize */
    • (alternatively if we already have the data in some byte array):
byte[] data = ...;
byte[] datagramBuffer = data;
int datagramBufferOffset = 0;
int datagramBufferUsed = data.length;
    • preparing the destination address:
SocketAddress remoteSocketAddress = ...;
    • creating the datagram:
DatagramPacket datagram = new DatagramPacket (datagramBuffer, datagramBufferOffset, datagramBufferUsed, remoteSocketAddress);
    • sending the datagram:
socket.send (datagram);
  • receiving a datagram:
    • preparing the datagram buffer (just like in the case of sending the datagram);
    • creating the datagram:
DatagramPacket datagram = new DatagramPacket (datagramBuffer, 0, datagramBufferSize);
    • receiving (waiting for) a datagram:
socket.receive (datagram);
    • obtaining the received offset and amount of received data:
      • (observation: the buffer and offset of a received datagram is never changed, it is kept from what we have initialized the datagram with;)
byte[] datagramBuffer = datagram.getData ();
int datagramBufferOffset = datagram.getOffset ();
int datagramBufferUsed = datagram.getLength ();
/* the received data is available in the buffer from the given offset */
    • obtaining the remote (the source) socket address:
SocketAddress senderSocketAddress = datagram.getSocketAddress ();
  • closing the socket:
socket.close ();

Complete examples[edit]

  • Ping:
    • both client and server side code;
    • the client sends a message to the server;
  • PingPong:
    • a refined version of the previous example;
    • the client sends a request and waits for a reply from the server;
  • MOTD (Message of the day):
    • both client and server side code:
    • the client listens on a specific port for messages;
    • the server sends a broadcast message to all the clients in the current network;

Java API[edit]

Further references[edit]

Assignments[edit]

  • MOTD enhancements:
    • enhance the MOTD example in the ways described below;
    • the server does not broadcast anymore the "messages of the day";
    • the server shall send the "message of the day" only to registered clients;
    • passive server discovery:
      • the server sends instead a broadcast every 2 seconds advertising itself as a MOTD server;
      • the client listens for such broadcasts, and when it finds one, it verifies if it has already registered to that particular server;
      • if the client is not already registered to that particular server it should send a message requesting it to be registered;
    • active server discovery:
      • the client sends regular broadcasting requesting MOTD servers to notice themselves to it;
      • the client waits for any notices from new servers and requests to register to them;
      • the servers should be careful not to notice themselves to clients already registered;
    • pushing messages: updated the protocol in order to allow clients to create new "message of the day";
  • see also Laboratory 3 assignment from previous year;

The current page is (in parts) a recompilation of the following pages (from previous year):

Retrieved from "https://beta.wikiversity.org/w/index.php?title=Computer_networks_--_2008-2009_--_info.uvt.ro/Course_2&oldid=42518"