CMSC 417-0101
|
PROJECT 4 -- PRELIMINARY
|
November 27, 1999
|
Due: December 12 Sunday 11:00pm (via submit)
Introduction
This project deals with achieving transport service over LRD
network channels.
The transport service consists of connection management and
reliable two-way data transfer between connected incarnations,
as explained in Note 4: Principles of Transport Protocols.
You are provided a specification of the transport service.
The specification of the LRD network layer service is, as before,
given by NetworkSocket.
You are to implement a transport protocol that provides the
transport service using the NetworkSocket service.
Specifically, the project consists of two interacting programs,
Client and Server.
The Client consists of three components
(each being one or more threads):
ClientTester, ClientEntity, and NetworkSocket.
The Server consists of three components
(each being one or more threads):
ServerTester, ServerEntity, and NetworkSocket.
You are to implement ClientEntity and ServerEntity.
You will be provided the others.
ClientTester and ServerTester are the users of the transport entities.
The pair of NetworkSockets provide the LRD channels
and are as in Project 3.
Transport Service
You are to implement two classes, ClientEntity and ServerEntity,
that provide connection management and reliable two-way byte stream
transfer. These classes can interact only via the NetworkSocket objects
Class ClientEntity must have the following interface:
-
Constructor ClientEntity( local IP address and port,
remote IP address and port, timeout value )
Constructs the client of a transport protocol.
Timeout signifies that the remote site is not reachable
(in this case, due to congestion in LRD channels
or due to the remote site closing).
-
RequestConnection()
Initiates a connection establishment attempt with server.
Blocks until either connection is established (returns OPEN),
connection is rejected (returns CLOSED),
or times out (returns TIMEOUT).
With respect to Note 4, an invocation of RequestConnection
corresponds to a ConnectRequest event followed by
the reception of an appropriate CRR,
the reception of an appropriate REJ,
or an Abort event.
-
RequestDisconnection( )
Initiates a disconnection attempt with server.
Blocks until connection is either closed normally
or disconnect request times out.
With respect to Note 4, an invocation of RequestDisconnection
corresponds to a DisconnectRequest event followed by
the reception of an appropriate message (DRACK, REJ, ...),
or an Abort event.
-
SendData( byte sequence )
Accepts byte string from local user (i.e., ClientTester)
to be transferred to remote user.
Iflocal resources cannot handle byte string,
it blocks until resources become free or until timeout.
Assume this is called only when open.
-
DataAcked( )
Returns when all data has been acked or timeout.
(Allows local user to determine that all data sent has been acked.)
Assume this is called only when open.
-
ReceiveData( byte sequence )
Returns byte string or timeout.
Blocks until data available to be delivered to local user
or time out occurs.
Assume this is called only when open.
-
At any time at most one call of any of the above methods is outstanding;
i.e., an above method is called only when all previous calls of these
methods have returned.
Class ServerEntity must have the following interface:
-
Constructor ServerEntity( local IP address and port,
remote IP address and port, timeout value )
Constructs the server of the transport protocol,
starting in closed (not accepting connections) state.
Timeout signifies that the remote client is not reachable
(in this case, due to congestion in LRD channels
or due to the remote site closing).
-
AcceptConnection()
Puts the server in a state where it accepts a connection request.
Blocks until a connection is established with client (returns OPEN),
or time out occurs (i.e., returns TIMEOUT,
indicating that no connectin attempt was observed before time out),
or StopAcceptingConnection() occurs.
-
StopAcceptingConnection()
Puts the server in a state where it does not accept connections.
Never blocks.
Assume it is called only when AcceptConnection() is blocked;
it unblocks AcceptConnection().
-
AwaitDisconnection()
Called only when server is open.
Blocks until the client requests disconnection (returns CLOSED),
or time out occurs (i.e., returns TIMEOUT,
indicating that no disconnection attempt was observed before time out).
-
SendData( byte sequence )
Accepts byte string from local user (i.e., ClientTester)
to be transferred to remote user.
If local resources cannot handle byte string,
it blocks until resources become free or until timeout.
Assume this is called only when open.
-
DataAcked( )
Returns when all data has been acked or timeout.
(Allows local user to determine that all data sent has been acked.)
Assume this is called only when open.
-
ReceiveData( byte sequence )
Returns byte sequence or timeout.
Blocks until data available to be delivered to local user
or time out occurs.
Assume this is called only when open.
-
At any time at most one call of any of the above methods is outstanding,
except for StopAcceptingConnection();
i.e., except for StopAcceptingConnection(),
an above method is called only when all previous
calls of these methods have returned.
Consider the execution of a corresponding pair of Client and Server entities.
At the client, the activity consists of a sequence of
RequestConnection, SendData, ReceiveData, Acked, and RequestDisconnection
calls (issued by ClientTester).
At the server, the activity consists of a sequence of
AcceptConnection, StopAcceptingConnection, SendData, ReceiveData, Acked,
and AwaitDisconnection calls (issued by ServerTester).
Your protocol must satisfy the requirements stated in section 2 of Note 4.
For example,
Each RequestConnection call starts a new incarnation of the Client.
Each AcceptConnection call starts a new incarnation of the Server.
An incarnation x may or may not become open. If it does, then it becomes
open to a corresponding incarnation y at the other site,
and that incarnation y must become open to this incarnation x.
Data sent by an incarnation in a connection
should be delivered in sequence to the other incarnation.
Transport Protocol
Your transport protocol can be composed of three parts,
a connection management protocol
and two one-way data transfer protocols,
as indicated in Note 4.
For the one-way data transfer protocol,
just use the protocol you have already developed for projects 2 and 3.