The goals of the network subsystem are to reliably transmit messages and data between Daimler-Benz after-sales database servers and dealer machines running the PAID system. The information should be accurate and delivered in a timely manner. All updates to the database should be pushed to dealers who are using the information using a multi-cast distribution policy.
Currently, the entire database is distributed using CD-ROM, microfiche, online, and paper methods to the various dealers. Redistribution occurs on a monthly basis.
The PAID Network subsystem will be designed to provide a method of communication between a dealer and the central database, as well as providing communication between the other individual subsystems of PAID. Specifically, the Network subsystem will allow a remote user to request information from the central database, and to receive updated information from the central database.
The Network subsystem will implement both pull and push functionality. Pull functionality will allow a dealer (on a remote machine) to request the transferral of data from the central database. Push functionality will allow a central database to send updated information to a dealer. Also, the system will allow updates to be multi-cast to multiple dealers. Transparently to the above mentioned functionality, the Network subsystem will provide on-the-fly compression (using a scheme such adaptive compression) to reduce network load. Error checking will also be incorporated to ensure that data passed over the Network is uncorrupted. The Network subsystem will monitor server load and network responsivity to assure that information is routed in the most effective way possible. The Network team is currently investigating third-party solutions such as Marimba/Castanet to handle push/pull communication modes and to implement such features as multicasting.
The Network subsystem will not be interacting with human users, instead the users of the Network subsystem will be interacting solely with other subsystems within PAID. The Network subsystem will expose an Application Programming Interface (API) via which these other subsystems will interact with the Network subsystem. Also, the internal workings of the Network subsystem will be transparent to the other subsystems.
Documentation will be provided that covers the specifics of the API, in terms which can be understood by the developers of the other PAID subsystems. The documentation will also cover how the Network subsystem will react under specific conditions. We will also be using JavaDoc to generate documentation from the coded implementation. All documentation, TogetherJ projects, and code, and libraries shall be managed via CVS.
The Network subsystem does not deal with specific machine-type constraints. Since the system will be implemented in Java, the code will be usable on a variety of machines. The type of connection used (Moden, Ethernet, ATM, ISDN, etc) will have an affect on the network subsytem's operation, in that the Network subsystem will attempt to determine the speed of the connection, and adjust the network parameters (such as TCP/IP window size and compression methods) in order to make full use of the connection speed and to minimize congestion.
The Network subsystem is expected to transmit at the highest speed allowable based on the connection between a remote machine and the central database. In addition, the Network subsystem may make use of compression techniques in order to maximize throughput. The estimated ratio of server to clients will be 1:150. In the event of a network overload, the network will use shared throughput and attempt to circumvent bottlenecks by transmitting packets along an alternate routes. Response time will be dependant on how quickly congestion is discovered. We estimate 5-7 transactions during peak times and 2-3 transactions during off-peak times. By using shared throughput we will balance the server high bandwidth with vs. the dealer low bandwidth. We will be using adaptive compression to reduce network load.
There are three exceptional situations that may arise. The first situation is network problems. In the case that the network becomes unreliable, any currently ongoing transmissions will be terminated, and both ends (the remote machine and the central database) will be informed of the interruption as well as the state of the transmission upon termination. The second possible situation is that the dealer (on a remote machine) may choose to terminate a transmission, in which case the central database will be informed of the situation and both ends will be informed of the state of the transmission at the time of termination. The third possibility is that the local program is terminated unexpectedly in the middle of a transfer (e.g. in case of power failure). In this case, the client would clear recieved information from its cache upon reboot and continue as if transfer never occured.
The network subsystem functions as the lowest layer or core of the PAID project. All messages sent over the network will be passed through this subsystem. The network subsystem looks at the client and server side as black boxes, meaning it does not recognize or account for any explicit interactions with other subsystems. All interfacing to this subsystem will be done through the Network API (NAPI). However, there are two main subsystems that we expect to interface with NAPI in order to provide the basic functionality of PAID. We anticipate the event/learning subsystem to pass data for automatic server to client updates through the network, in the form of either a point to point or multi-cast message. We also expect the database subsystem to request and receive desired information from the server through the network subsystem. All interactions between these subsystems will take place on the CORBA bus through a Java interface.
This subsystem must provide fast, portable, and reliable information transportation over the network for the PAID system. In order to maximize speed efficiency, the network subsystem will provide compression on the fly, be selective (multi-cast or point to point) to the amount of information transported (to prevent unnecessary lags), and optimize routing of the information (in terms of time). To ensure portability, the subsystem is 100% pure Java. This means any hardware/operating system which has a Java Virtual Machine will be able to route information through PAID over the network. Reliability is guaranteed as the subsystem follows the ISO Open System Interconnect (OSI) model.
As more dealers are added to the system, scalability issues might have to be considered if the network's response is being depreciated by an overload of responses to the server. We do not anticipate any modifications outside of this as we expect the network subsystem to be very stable. We achieve this by using Java as our language as it is cross-platform and in wide use. We also follow the established ISO Open System Interconnect (OSI) model to comply with set standards of the industry.
This is not an issue because we are using Java Sockets, which are independent of the actual hardware they are running on.
All user access to data will be controlled by authentication and database subsystems. Transport over the Daimler-Benz intranet and extranet needs no special security measures. Transport over the general internet needs to be encrypted to insure security. Physical security is important for both the database servers and for local copies of the database on dealer machines.
System installation will be performed along with the rest of the application. Little to no maintenance will be required for the network subsystem after the initial setup stage. Neither will any persistent data be externally accessible.
System will be developed with Java (ver. 1.1). Object and CASE models will be created with Together/J. Source Control will be handled using CVS.
[Push] [Pull] [Compression] [Routing] [Integrity Check]
Mr. Benz has come out. with a new car model. He adds information about the new model to the central database in Germany. This new data needs to be transmitted to all dealers interested in this class of car. The central database tells the network to announce the availability of the new information to the relevant dealers. Bob (a dealer in San Francisco) receives the notification and requests, via the network subsystem, that the data be sent immediately. The network subsystem will be making use of the CORBA bus to remotely call procedures on the database server. The central database, upon receipt of the acceptance, now sends the updated information to Bob?s database via the network. Jim (another dealer in Miami), is busy with clients and requests that he be notified later. The network sends the request to the central database, which will log this request and later send Jim another notification.
Humphrey, a Diemler-Benz dealer in Edinburg, has decided to expand his model selection with a new S-class model. He logs into the PAID system, and fills out the a form to request information on the model. He clicks the submit button, and the his local database discovers that it doesn?t contain the desired information, so it passes the request to the network subsystem. The network subsystem uses CORBA bus to a remote procedure call (RPC) to request that the central database submit the information. The central database will then use the network subsystem to transmit the request information back to the database to Humphrey?s machine.
All information sent though the network will be compressed using adaptive on-the-fly compression.
Trent, a packet traveling from the database server to the local database encounters congestion along a given route. After observing the congestion at a particular node, network will route furture packets around the congested node.
Whenever a packet of information is to be sent, we will perform a CRC and add it to the packet. Whenever a packet if received, we will check the CRC to make sure the data was received properly. If the packet was corrupted, we will request the retransmission of the packet.
[Open/Close Session] [Server Side Push] [Client Side Push] [Push Delay] [Pull]
Network does not have any direct interaction with the users. Therefore, we do not have a user interface.
bandwidth - the bits of data per second able to be sent over a given medium. bottleneck - a point during data transmission at which the information is making the slowest progression. broadcast - sending a packet out on the network for all machines to read and interpret. caching - temporary storage of requested files to be used in leu of another network access for the same data within the same session. central database - the master copy of the database residing at Daimler-Benz headquarters. compression - making a file smaller by encoding its contents. adaptive - optimizing compression for current data. on-the-fly - the process of compressing data as it is being sent over the network. cyclic redundancy check (CRC) - detects error in packets and other data. database server - machines with partial or full copies of the central database to be accessed by nearby dealer machines. dealer machine - computer running the PAID system used by an affiliated Daimler-Benz dealer. encryption - making a file unreadable to provide security. multicast - the concept of sending a packet to selected destinations, but not all inclusive. (i.e. the packet would only be read by a subset of all machines on the network--contrast with broadcast.) network congestion - the state when the network routers are receiving more packets than they can buffer, resulting in the loss of information. packets - data tagged with information to aid its routing through the network. The largest information unit sendable over the network. pull - the act of a dealer requesting information from the database servers. push - the act of the database servers notifying the dealer machines of an update and sending the update to the dealer machines. throughput - the actual bandwidth that you are getting. updates - changes made to the central database.Last modified: Fri Oct 16 17:08:49 EDT 1998