Presentation is loading. Please wait.

Presentation is loading. Please wait.

NETWORK SOFTWARE Software structuring technique. Network Software Protocol Hierarchies Design Issues for the Layers Connection-Oriented and Connectionless.

Similar presentations


Presentation on theme: "NETWORK SOFTWARE Software structuring technique. Network Software Protocol Hierarchies Design Issues for the Layers Connection-Oriented and Connectionless."— Presentation transcript:

1 NETWORK SOFTWARE Software structuring technique

2 Network Software Protocol Hierarchies Design Issues for the Layers Connection-Oriented and Connectionless Services Service Primitives The Relationship of Services to Protocols

3 Protocol Hierarchies Most networks are organized as a stack of layers or levels, each one built upon the one below it The name of each layer, its content and functions, the number of layers, differ from network to network The purpose of each layer is to offer certain services to the higher layers, shielding those layers from the details of how the offered services are actually implemented

4 Protocol Hierarchies - layers, protocols, and interfaces ..

5 Protocol Hierarchies: Structure 5 Layered structure: Protocol - rules and convention of data exchange between layer n of host1 and layer n of host2 Peers - entities that locally implement the functionality of a given layer (processes, hardware devices, even humans); peers communicate by using the protocol Interface - the set of primitive operations and services that lower layer provides to the upper Physical media - through it the actual communication occurs - there is the signal carrier

6 Network Software 6  Considerations: Virtual exchange between the equivalent level layers of two hosts according the protocols Physical exchange between the neighbor layers of one host according to the interface Portability of the layers: based on clear simple interfaces and well defined set of functions of each layer

7 Network Architecture 7 Network architecture - the set of layers and protocols; ignores the interfaces as the interfaces of the hosts in a network may differ Protocol stack - the list of protocol hierarchy in the network; matches the layered structure Analogy to the network protocol stack – two philosophers (peer processes) speaking different languages (English and French) want to communicate

8 The philosopher-translator-secretary architecture

9 Protocol Hierarchies How to provide communication to the top layer of a five-layer network? A message, M, is produced by an application process running in layer 5 and given to layer 4 for transmission Layer 4 puts a header in front of the message to identify the message and passes the result to layer 3 The header includes control information, such as sequence numbers, to allow layer 4 on the destination machine to deliver messages in the right order if the lower layers do not maintain sequence

10 Information flow supporting virtual communication in layer 5.

11 Protocol Hierarchies In most networks, there is nearly always a limit imposed by the layer 3 protocol, so layer 3 must break up the incoming messages into smaller units, packets, adding a layer 3 header to each packet - here M is split into two parts, M 1 and M 2 Layer 2 adds not only a header to each piece, but also a trailer, and gives the resulting unit to layer 1 for physical transmission At the receiving machine the message moves upward, from layer to layer, with headers being stripped off as it progresses. None of the headers for layers below n are passed up to layer n

12 Network Architecture 12  Receiving of the message M at the destination machine consists in: moving of its packets upward the layers, stripping of control header and trailers, merging the packets in a message and interpreting the message by the application  Lower layers have hardware implementation  Medium layer[s] have firmware implementation  High layers have software implementation

13 Design Issues for the Layers Addressing Error Control Flow Control Multiplexing Routing

14 Addressing  A network normally has many computers, some of which have multiple processes  A mechanism is needed for a process on one machine to specify with whom it wants to talk  As a consequence of having multiple destinations, some form of addressing is needed in order to specify a specific destination

15 Error control Physical communication circuits are not perfect – errors occur Many error-detecting and error-correcting codes are known, but both ends of the connection must agree on which one is being used The receiver must have some way of telling the sender which messages have been correctly received and which have not

16 Flow control Not all communication channels preserve the order of messages sent on them The protocol must make explicit provision for the receiver to allow the pieces to be reassembled properly How to keep a fast sender from swamping a slow receiver with data – either have some kind of feedback from the receiver to the sender, or limit the sender to an agreed-on transmission rate

17 Multiplexing Sometimes it is expensive to set up a separate connection for each pair of communicating processes, so the underlying layer may decide to use the same connection for multiple, unrelated conversations – multiplexing Must be done transparently and can be used by any layer Needed in the physical layer, for example, where all the traffic for all connections has to be sent over at most a few physical circuits

18 Routing When there are multiple paths between source and destination, a route must be chosen Sometimes this decision must be split over two or more layers To send data from London to Rome, a high-level decision might have to be made to transit France or Germany based on their respective privacy laws A low-level decision might have to made to select one of the available circuits based on the current traffic load

19 Connection-Oriented and Connectionless Services 19  Connection-oriented service: establishes the connection from point to point; caries the exchange, preserving the order of the bitstream and releases the connection, analogy - telephone system (dial, talk, hang up)  Connectionless service: each message is provided with full destination address and it is routed through the system independently to rest of message stream, analogy – postal system  QoS (quality of service) - reliability to losing data

20 Quality of service For a file transfer, the owner of the file wants to be sure that all the bits arrive correctly and in the same order they were sent (i.e. need acknowledgements) Acknowledge receipts produce – communication overhead and – delays For some applications, the transit delays introduced by acknowledgements are unacceptable – for example - digitized voice traffic – better users to hear a bit of noise on the line from time to time than to experience a delay waiting for acknowledgements, or during a video conference, having a few pixels wrong is no problem

21 Quality of service Unreliable (meaning not acknowledged) connectionless service is often called datagram service, in analogy with telegram service, which also does not return an acknowledgement to the sender At some occasions not having to establish a connection to send one short message is desired, but reliability is essential – then an acknowledged datagram service can be provided For the request-reply service. In this service the sender transmits a single datagram containing a request; the reply contains the answer - client-server model: the client issues a request and the server responds to it

22 Connection-Oriented and Connectionless Services  Six different types of service.

23 Why unreliable communication? Reliable communication (in our sense, that is, acknowledged) may not be available – (Ethernet network - packets can occasionally be damaged in transit and it is up to higher protocol levels to deal with this problem) Delays inherent in providing a reliable service may be unacceptable, especially in real-time applications such as multimedia For these reasons, both reliable and unreliable communication coexist

24 Service Primitives A service is formally specified by a set of primitives (operations) available to a user process to access the service Primitives:  request some elementary service action;  inform the service process for some event in the peer entity When the protocol stack is located in the operating system, the primitives are normally system calls The primitives for connection-oriented service are different from those of connectionless service

25 Service primitives for implementing a simple connection-oriented service

26 1. LISTEN – the server is prepared to accept incoming connections; makes a blocking system call - after executing the primitive, the server process is blocked until a request for connection appears 2. client process executes CONNECT to establish a connection with the server CONNECT call specifies who to connect to - parameter giving the server's address The OS sends a packet to the peer asking it to connect and the client process is suspended until there is a response

27 Simple client-server interaction on a connection-oriented network

28 Service primitives for implementing a simple connection-oriented service 3. packet arrives at the server, processed by the OS – it realizes that the packet requests a connection and checks if there is a listener (if LISTEN was executed earlier), if there is no listener – the result is undefined, or waits for a short time a LISTEN to appear 4. System unblocks the listener 5. System sends an acknowledgement (ACK) 6. After the client receives ACK, client and server processes are running – a connection is established

29 Service primitives for implementing a simple connection-oriented service 7. Server executes RECEIVE to prepare to accept the first request – this is done immediately after being released from LISTEN, before ACK gets back to the client The RECEIVE call blocks the server 8. Client executes SEND to transmit its request (3 in the figure) 9. Client executes RECEIVE to get the reply 10. Server receives request, process is unblocked and request is processed (work is done) 11. Server executes SEND to pass the answer to the client

30 Service primitives for implementing a simple connection-oriented service 12. Client receives the answer, unblocks the process, it looks at the received data - if there are additional requests – repeat the procedure from 8 - if there are no other requests – 13. 13. Client sends DISCONNECT to terminate the connection (usually – DISCONNECT is a blocking call, suspending the client 14. Server gets the packet, issues its DISCONNECT and releases the connection 15. Client receives DISCONNECT and its process gets released

31 Relationship Services -Protocols Services and protocols are distinct concepts A service is a set of primitives (operations) that a layer provides to the layer above it The service defines what operations the layer is prepared to perform on behalf of its users A service says nothing at all about how these operations are implemented A service relates to an interface between two layers, with the lower layer being the service provider and the upper layer being the service user

32 Relationship Services -Protocols A protocol is a set of rules governing the format and meaning of the packets/messages that are exchanged by the peer entities within a layer Entities use protocols to implement their service definitions Entities are free to change their protocols at will, provided they do not change the service visible to their users the service and the protocol are completely decoupled services relate to the interfaces between layers protocols relate to the packets sent between peer entities on different machines

33 Services to Protocols Relationship


Download ppt "NETWORK SOFTWARE Software structuring technique. Network Software Protocol Hierarchies Design Issues for the Layers Connection-Oriented and Connectionless."

Similar presentations


Ads by Google