![[INET'99]](/web/20080828200656im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/inet99sm.gif)
![[ Up ]](/web/20080828200656im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/up.gif)
![[Prev]](/web/20080828200656im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/prev.gif)
![[Next]](/web/20080828200656im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/next.gif)
Norihiro ISHIKAWA <isic@isl.ntt.co.jp>
Shingo KINOSHITA <kinosita@isl.ntt.co.jp>
Osamu TAKAHASHI <osamu@isl.ntt.co.jp>
NTT Information and Communication Systems Laboratories
Japan
Push information delivery services have been emerging as a new service over the Internet. However, most of these services are pseudo-push information delivery services in which clients periodically access information delivery servers. Those pseudo-push information delivery services do not resolve issues such as scalability on the increase of clients and real-time delivery of information. While it is expected that Internet protocol (IP) multicast is a core technology for push information delivery services over the Internet, IP multicast has not been fully deployed over the Internet at this time. In this paper, we propose a new architecture for push information delivery over the existing Internet that does not support IP multicast. We also describe the application of our architecture to the news delivery system.
Push information delivery services such as PointCast Network [1] have been emerging as a new service over the Internet. However, most of those services are pseudo-push information delivery services in which clients periodically access information delivery servers. Those pseudo-push information delivery services do not resolve issues such as scalability on the increase of clients and real-time delivery of information.
It is expected that Internet protocol (IP) multicast is a core technology for push information delivery services over the Internet. The deployment of IP multicast has been realized by multicast backbone (Mbone) [2], a virtual experimental IP multicast network over the Internet. However, IP multicast has not fully deployed over internet service providers (ISPs) at this time.
In this paper, we propose a new architecture for push information delivery over an IP network that does not support IP multicast. Our architecture resolves the above issues on pseudo-push information delivery services. We have implemented a prototype system based on our architecture on various platforms. Implementation results are also described. In addition, we describe the application of our architecture to the news delivery system called RealPush Network [3].
The proposed architecture for push information delivery is shown in Figure 1. Our architecture consists of information delivery servers, relay servers, and clients. To retain the scalability on the increase of clients, multiple relay servers form a relationship that has a tree structure. Each relay server may be connected with a relay server as a parent server. Each relay server may be connected with multiple relay servers as a child server. A relay server that does not have a parent server is the highest level server. To deliver information, an information delivery server is connected with the highest level server. A relay server that does not have a child server is the lowest level server. To receive delivered information, a client is connected with the lowest level server.
Figure 1. Architecture for Push Information Delivery
An information delivery server requests the highest level server to deliver information by designating the delivery channel. By means of the delivery channel, information is delivered to multiple clients via multiple relay servers. A delivery channel is defined for each type (e.g., stock information and weather information) of information to be delivered. We have defined two kinds of delivery channels: a real-time channel for video and audio delivery and a reliable channel for news delivery.
A delivery channel is established between a parent server and a child server, as well as between a relay server and a client. A delivery channel is dynamically established, based on the delivery request of a client. When a client requests information to be delivered, it sends a Join Channel request to a relay server. The Join Channel request is propagated toward the highest level server via intermediate relay servers, and the delivery channel is established simultaneously. When a client requests information delivery to be terminated, it sends a Leave Channel request to a relay server. The Leave Channel request is propagated toward the highest level server via intermediate relay servers, and the delivery channel is released simultaneously. A client may join a delivery channel and leave it at any time.
A delivery channel is identified by a delivery channel identifier. The length of a delivery channel identifier is 48 bits so that our architecture may be interconnected with IP multicast networks. When our architecture is interconnected with an IP multicast network, a group address (i.e., class D IP address) is set to the higher 32 bits of a delivery channel identifier, and a destination port number is set to its lower 16 bits. When our architecture is not interconnected with an IP multicast network, any value may be set to a delivery channel identifier.
A delivery tree is defined for each delivery channel. A specific relay server is defined as the root of a delivery tree (i.e., highest level server). It is assumed that a relay server is able to deliver information to 50 clients simultaneously. In this case, an information delivery server is able to deliver information to up to 2,500 clients simultaneously, if the highest level server and 50 intermediate relay servers are installed. Thus, scalable push information delivery is realized by adopting a delivery model that has a tree structure.
To realize our architecture, we have defined a new protocol called delivery channel management protocol (DCMP). DCMP is defined over transmission control protocol/Internet protocol (TCP/IP) and user datagram protocol (UDP)/IP. DCMP does not use IP multicast. The layer model of DCMP is shown in Figure 2.
Figure 2. Layer Model of DCMP
DCMP provides the following functions:
The messages of DCMP are shown in Table 1.
| Message | Parameters |
|---|---|
| Join Channel | Delivery Channel Identifier, Authentication |
| Join Ack | Delivery Channel Identifier |
| Join Nak | Delivery Channel Identifier, Reason |
| Leave Channel | Delivery Channel Identifier |
| Send | Delivery Channel Identifier, Source IP Address, Payload Type, Information |
| Delivery | Delivery Channel Identifier, Source IP Address, Payload Type, Information |
A Join Channel message is used when a client requests to join a delivery channel. A Leave Channel message is used when a client requests to leave the delivery channel. Both Join Channel and Leave Channel messages are propagated toward the root of a delivery tree (i.e., the highest level server). The above messages for establishment and release of a delivery channel are transmitted over TCP/IP.
A Send message is used when an information delivery server requests the root of a delivery tree to deliver information. A delivery message is used when a relay server delivers information to a child server or a client using the established delivery channel. The above messages for delivery of information are transmitted over TCP/IP in the case of a reliable channel. Those messages are transmitted over UDP/IP in the case of a real-time channel.
In this section, we describe the detailed procedures for push information delivery (Figure 3).
Figure 3. Scenario for Push Information Delivery
When Information to deliver occurs, an information delivery server may immediately deliver information to clients. An information delivery server requests information delivery by sending a Send message to a relay server that is designated as the root of a delivery tree. A Delivery Channel Identifier parameter in a Send message designates the delivery channel on which information is delivered.
A client requests the start of information delivery by sending a Join Channel message to a relay server. A Delivery Channel Identifier parameter in a Join Channel message designates the delivery channel on which information is delivered. The Join Channel message is propagated toward the root of a delivery tree. It should be noted that a relay server sends a Join Channel message to a parent server only once, regarding the delivery channel. When a relay server receives a Join Channel message from a child server or a client, it does not resend a Join Channel message to a parent server, if it has already sent the Join Channel message to the parent server, regarding the same delivery channel.
When the root of a delivery tree (i.e., highest level server) receives a Join Channel message, it responds with a Join Ack message to the child server or the client, if it accepts the Join Channel request. The Join Ack message is propagated toward the client, and the delivery tree is established simultaneously. When the root of a delivery tree receives a Join Channel message, it responds with a Join Nak message to the child server or the client, if it rejects the Join Channel request because of some reason (e.g., lack of resource). The Join Nak message is propagated toward the client, and the delivery tree is not established.
The root of a delivery tree (i.e., highest level server) receives Information to deliver as the parameter of a Send message sent from an information delivery server. The highest level server checks whether the delivery channel on which information is to be delivered is already established or not. If the delivery channel is established, the highest level server delivers information to child servers and/or clients as the parameter of a Delivery message. If the delivery channel is not established, the highest level server simply discards information received from the information delivery server.
Similarly, when a relay server receives information as the parameter of a Delivery message from a parent server, it delivers information to child servers and/or clients, as the parameter of a Delivery message. Thus when information to deliver occurs, it is immediately delivered from an information delivery server to clients, via multiple relay servers.
A client requests the stop of information delivery by sending a Leave Channel message to a relay server. A Delivery Channel Identifier parameter in a Leave Channel message designates the delivery channel that the client is to leave. When a relay server receives a Leave Channel message from a client, it releases the delivery channel between the relay server and the client. If the released channel is the last channel with a client or a child server regarding the delivery channel, the relay server sends a Leave Channel message to a parent server. Thus a Leave Channel message is propagated from a client to the highest level server via multiple relay servers, and the delivery channel is released simultaneously.
Since it is expected that IP multicast is a core technology for push information delivery services, it is very important for our architecture to be able to interwork with IP multicast networks. Since IP multicast is inherently unreliable, we describe the mechanism for the interworking between real-time channels of our architecture and IP multicast networks in this section (Figure 4). In this mechanism, the highest level server that is the root of a delivery tree acts as the gateway with an IP multicast network.
Reliable multicast is required so that reliable channels of our architecture may interwork with IP multicast networks. We describe the mechanism for the interworking between reliable channels of our architecture and reliable multicast in Section 7.
Figure 4. Interworking with IP Multicast Networks
When a client requests the start of information delivery, it sends a Join Channel message to a relay server. The Join Channel message is propagated toward the highest level server that is the root of a delivery tree. When the highest level server receives the Join Channel message, it starts receiving IP multicast datagrams by sending a Host Membership Report message of Internet group management protocol (IGMP) [4] to an IP multicast network. The higher 32 bits of a Delivery Channel Identifier parameter in a Join Channel message is set to a Group Address (i.e., class D IP address) parameter in a Host Membership Report message.
When the highest level server then receives an IP multicast datagram from the IP multicast network, it transforms the IP multicast datagram received into a Delivery message and sends it to child servers and/or clients.
When a client requests the stop of information delivery, it sends a Leave Channel message to a relay server. The Leave Channel message is propagated toward the highest level server. When the highest level server receives the last Leave Channel message regarding the delivery channel, it stops receiving IP multicast datagrams from an IP multicast network.
When the highest level server receives a Send message from an information delivery server, it transforms the Send message received into an IP multicast datagram and sends it to an IP multicast network. The higher 32 bits of a Delivery Channel Identifier parameter in a Send message is used as the destination IP address of an IP multicast datagram. The IP multicast datagram is delivered toward clients (i.e., receiving hosts) on the IP multicast network.
We have been implementing a prototype system based on our architecture on UNIX and Windows 95/NT (Figure 5).
Figure 5. Implementation
We have implemented the functions of both information delivery server and client as libraries on UNIX and Windows 95/NT. We have implemented the function of a relay server as daemon on UNIX and service on Windows NT. In addition, we have also implemented the function of a client as class libraries of Java. Table 2 summarizes the implementation environment of our prototype system.
| Function | Implementation |
|---|---|
| Information Delivery Server | UNIX (library), Windows NT/95 (library) |
| Relay Server | UNIX (daemon), Windows NT (service) |
| Client | UNIX (library), Windows NT/95 (library), Java (class library) |
Since we have implemented our prototype system using standard socket libraries on UNIX, our prototype system can run under various kinds of UNIX systems. Our implementation of a relay server also supports the interworking with IP multicast networks, which is described in Section 5.
A single system can act as an information delivery server, a relay server, and a client simultaneously. In this case, an information delivery server, a relay server, and a client on the same system communicate each other, using local interprocess communications.
Table 3 shows the library functions that are provided for push information delivery applications on an information delivery server and a client.
| Function Name | Description |
|---|---|
| dcmp_connect | An information delivery server connects with a relay server defined as the root of a delivery tree. |
| dcmp_disconnect | An information delivery server releases the connection with a relay server. |
| dcmp_send | An information delivery server requests a relay server to deliver information. |
| dcmp_recv | A client receives information delivered from relay server. |
| dcmp_join | A client requests the start of information delivery to a relay server. |
| dcmp_leave | A client requests the stop of information delivery to a relay server. |
We are developing a news delivery system called RealPush Network [3] using IP multicast. RealPush Network consists of information delivery servers (RealPush Server), clients (RealPush Reader), and IP multicast networks.
A RealPush Server delivers various contents such as news, advertisement information, and ticker information using delivery channels. Such contents are delivered to multiple clients simultaneously over IP multicast networks. A user joins a delivery channel and views contents delivered on the delivery channel using a client software called RealPush Reader (Figure 6).
Figure 6. Graphical User Interface of RealPush Reader
Protocols for RealPush Network consist of the protocol for contents delivery and the protocol for delivery channel announcement.
We have developed the protocol for contents delivery, which is called item publishing protocol (IPP). IPP is substantially the extension to hypertext transfer protocol (HTTP) for use with IP multicast. An IPP message consists of the header and the contents to deliver. The following attributes of the contents are described in the header of an IPP message.
IPP messages are reliably delivered toward multiple clients using reliable multicast transport protocol (RMTP) [5] jointly developed by NTT and IBM Japan.
RealPush Network uses session description protocol/service access point (SDP/SAP) extensively deployed over Mbone as the protocol for delivery channel announcement. A RealPush Server periodically sends delivery channel information to clients using SDP/SAP. Delivery channel information includes the delivery channel name and the group address and the port number that are used for the delivery channel.
We have applied our architecture to RealPush Network so that a RealPush server may deliver its contents toward clients on networks that do not support IP multicast. The application of our architecture to RealPush Network is shown in Figure 8. As shown in Figure 7, a RealPush server on an IP multicast network delivers its contents toward clients on IP networks as well as clients on networks that do not support IP multicast.
Figure 7. Applications to RealPush Network
Since IPP messages should be reliably delivered, they are sent using reliable channels of our architecture. When the highest level server receives an IPP message from a RealPush Server using RMTP, it sends the IPP message received toward clients using the reliable channel. In this case, the highest level server acts as the gateway between RMTP and reliable channels (Figure 8).
Figure 8. Gateway between RMTP and Reliable Channels
SDP/SAP messages are sent using real-time channels of our architecture. When the highest level server receives a SDP/SAP message from a RealPush Server using UDP/IP multicast, it sends the SDP/SAP message received toward clients using the real-time channel. This mechanism is described in Section 5.
In this paper, we propose a new architecture for push information delivery. We have implemented a prototype system based on our architecture and applied it to a news delivery system called RealPush Network. As a result, a RealPush server has come to seamlessly deliver its contents toward clients on IP multicast networks as well as clients on networks that do not support IP multicast.
We are planning to do field trials of our prototype system with RealPush Network on various sites. Although we will do performance evaluation of our prototype system, we then intend to apply our architecture to applications other than RealPush Network.