network software software structuring technique. network software protocol hierarchies design issues...
TRANSCRIPT
NETWORK SOFTWARE
Software structuring technique
Network Software
• Protocol Hierarchies• Design Issues for the Layers• Connection-Oriented and Connectionless
Services• Service Primitives• The Relationship of Services to Protocols
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
Protocol Hierarchies - layers, protocols, and interfaces
.
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
Network Software6
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
Network Architecture7
• 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
The philosopher-translator-secretary architecture
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
Information flow supporting virtual communication in layer 5.
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, M1 and M2
• 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
Network Architecture12
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
Design Issues for the Layers
• Addressing
• Error Control
• Flow Control
• Multiplexing
• Routing
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
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
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
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
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
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
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
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
Connection-Oriented and Connectionless Services
Six different types of service.
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
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
Service primitives for implementing a simple
connection-oriented service
Service primitives for implementing a simple connection-oriented service• 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
Simple client-server interaction on a connection-oriented network
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
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
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
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
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
Services to Protocols Relationship