fliu@uvicctr.UUCP (Fang Liu) (03/29/89)
I am working on a remote execution manager system on network of SUN
workstations. We need to implement a broadcast facility in order to
speedup communication between workstations. Sun networking does not
support broadcast and we are not suppose to change the operating system.
Has anyone worked on this problem? Any ideas, suggestions and refrences
are welcome. Thanks.
Frances
Frances Liu <fliu@uvunix.UVic.ca>
UUCP: ...!{ubc-vision,uw-beaver,ssc-vax}!uvicctr!fliu
BITNET: fliu@uvunix.bitnetmiker@central.sun.com (Mike Raffety) (04/07/89)
Sun has internally implemented something called "broadcast RPC"; the source code is available for the asking if you talk to the right people. Attached is a document entitled "HOW_IT_WORKS" from the tape I got from Raj; hope it helps: Reliable Broadcast Toolkit (RBT) Specification Saul G. Wold Raj Benjaram January 1, 1988 Version 1.0 Revision History: ----------------- Version 1.0 1/1/88 Introduction: ------------- This document describes the toolkit that Raj and Saul have prototyped using both RPC's and Sockets as the underlying transports. It is meant as a specification for the final version that will be shown at the SIA show in early February. This document can and probably will change as development continues. Purpose: -------- The purpose of the toolkit is to show the capabilites of the Sun Workstation networking. RBT is designed to use the RPC or Socket mechanisms to show the flexiblity of the Sun. RBT uses the broadcast ability of both these interfaces to move the packet quickly from the host server to all the clients without incurring large overhead of sending to each individual system. Because the broadcast mechanism uses the UDP transport layer which is not "reliable", we have encapsulated the data into a packet that contains sequencing data along with other data to ensure the client can re-request a missed packet. Using the RPC as the error and report message passing system assures reliability of those messages getting to their destination. Server: ------- The Server system is broken into two separate parts; there is the broadcast server and the data server. Both of these processes will run on the server machine and will pass data using shared memory. The shared memory will be loaded by the data server using a ring buffer method, where there are 3 available buffer to start with and as one gets loaded with data it is marked as data ready and goes on to the next buffer. While the broadcast server is looking for a data ready buffer to use, it is sending a heartbeat packet every timeout period, which will be configurable by the admin. When the server sees a data ready buffer it reads the buffer and broadcasts the data onto the net. It then marks the shared memory buffer as free and looks for the next data-full buffer. The broadcast server while always checking the shared memory is also checking to see if there are any new or existing clients that need a missed or out of order packet which are sent using RPC calls to the server. If the server receives any of these control messages, it responds back using the return to the RPC that made the request. The broadcast server can use either RPC's or sockets as the transport layer. In both cases the broadcast method is used to ensure all machines on the net receive the data. Server Tool: ------------ The Server Tool is based on the broadcast server. It is used to simulate the data server by setting the amount of data to be broadcast on the net with a slider that will take the data speed in Kilobits from 1K bits/sec to 3000K bits/sec. The tool will also have a log area that will record the time it took to send N Kilobits and compute a Kbs/sec number from that. The Log area will also report receiving any client requests to the server for starting service or ending service to that client. Also in the server control panel will be buttons for holding a packet past the timeout period, and for switching two packets to test the out of order functions. The server will report making these changes to the data stream and then report as each of the clients requests the missed packet or reports the out of order packet. Client: ------- The Client side of the toolkit is made up of a receiver and the actual client. Again, both these programs are linked with shared memory. The receiver listens to the network on the defined socket or predetermined RPC program number. When the client first starts up it pulls one packet off of the net and uses it as a base, the client opens up the packet and sets it sequencing to the sequence number in the packet. It also uses the hostname in the packet to send a START control message to that server so that when the client receives more packets it will know that they should be used. The server will continue to include the client in the broadcast list until an END control message is received. The client reads the packet off the net and checks the sequence numbers to make sure that the packets are received in the correct order, and also be able to report that a packet has not been received. When a packet does not come after a certain timeout period a RESEND packet is send with the sequence number through RPC's and the server returns the correct data. If no packet is received after a timeout period then a MISSED control RPC is sent. After the client has made sure that the message is in the correct order and for this machine then it places the data into a shared segment along with a time stamp. The client that presents the data to the user then searchs the memory segment for the most recent segment and takes the data. If the data is the right kind of data then the client will use it otherwise it will drop it. Client Tool: ------------ The Client tool that can be used with the Server tool to monitor the client side of RBT. It receives the data from the server and times the speed of the packets. It will report in a log area when ever it does not receive a packet or when a packet is missed because of a timeout. It will also report if it receives data that is not for it. Control Messages: ----------------- These are the messages that are sent from the client to the server using RPC's with information in the arguments and return information from the server. START: This message is sent when a client wants to start a a new session with a server. It includes the clients host number (the last component of its internet address), flags for control flags and which service the client expects. The return information contains timeouts and the server host an service name for the client. END: This message is sent to the server to remove the client from the host list. CONFIG: This message requests the server to send its config- uration information in the return results. The configuration information is the same that is sent to the client when a start message is sent. RESEND: This message is sent to server when the client requests a resend of a out of order packet. It includes the the sequence number of the out of order packet. The server returns to the client the out of order data packet. MISSED: This message is sent to server when the client requests a resend of a missed packet. It includes the the sequence number of the missed packet. The server returns to the client the missed data packet. Broadcast Packet: ----------------- The broadcast packet contains the data and some control information. In the header of the packet is the following data: Timestamp: The time the message was sent on the server. Sequence #: The number of the packet to keep order. Process Id: The process id of the server insures uniqueness. Host Name: Host name of the server. Host Mask: The mask of all the clients that will receive the data. Data: The data that is sent by the server to the client.
bzs@bu-cs.bu.edu (Barry Shein) (04/19/89)
>...Sun networking does not >support broadcast and we are not suppose to change the operating system. >Has anyone worked on this problem? Any ideas, suggestions and refrences >are welcome. Thanks. Sun certainly does support broadcasting, see the NIT interface, there was a version of ProxyArp distributed a while back which could serve as a model (I had distributed one earlier but the part you'd be interested is in the proprietary source code, it was derived from Sun's rarpd server.) -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
fliu%uvicctr.UVic.CA@central.sun.com (Frances Liu) (04/25/89)
Hi Mike, Thank you for your response to my posting. It was indeed very helpful and relevant to our current research project. We have a remote execution manager that is developed on top of the UNIX kernel. However the communications between processes are carried out on a one-to-one basis. This is not very efficient especially when we have replicate child processes that need to communicate with the parent process. Thus we are required to improve the communication system by introducing muiltcast facility. However most of the current developments for multicast facility require modification to the UNIX kernel, which is not acceptable to our environment. We would like to have this facility built as an interface between the application programs and the UNIX kernel but without any modification to the kernel. The "Reliable Broadcast Toolkit (RBT)" which you mentioned seems interesting and I think it might come in handy for our enviroment. I wonder how one can get hold of the source code. Who should I contact? Where can I reach these people who have the source code? You mentioned about a person name Raj, how could I get in touch with him? Do you have his email address? I would appreciate you could provide the above information. Thanks, Frances