Received: from ATHENA-AS-WELL.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA19091; Fri, 4 Dec 92 18:00:27 EST Received: from NOBUNAGA.MIT.EDU by Athena.MIT.EDU with SMTP id AA29289; Fri, 4 Dec 92 18:00:22 EST Message-Id: <9212042300.AA29289@Athena.MIT.EDU> Received: by ceci.mit.edu id AA00991g; Fri, 4 Dec 92 18:03:29 EST Date: Fri, 4 Dec 92 18:03:29 EST From: Tomi Tominaga To: jud@Athena.MIT.EDU, pbailey@Athena.MIT.EDU, mau@ceci.mit.edu, aybee@Athena.MIT.EDU, harada@Athena.MIT.EDU Subject: Memo of the meeting Hi. I circulate a brief memo of the meeting along with a resume I made. I seem to have been lack in the application`s point of views in this resume. In the meeting we decided to collect wish list for AM2 networking part. Thank you. Tomi. -- MEMO --------------------------------------------------------- Naming space --- how to identify objects. Local location service per host what information is stored here ? application on the host the address of global location service Glabal location service per network Interaction of these services needed RPC asynchronous messaging In PC or Mac. how to implemented ? RPC with AppleTalk ? RPC with IPX/SPX ? PC-NFS for Macintosh ? Suport of RPC and underlying protocols ? PC(Mac) --- PC(Mac) PC --- Mac Unix --- Mac Unix --- PC We need to devise an infrastructure on this complexity. Needs investigation. Overhead of RCP with TCP Can we get file descriptor of the connection underlying RPC ? Yes. We can use some means of notification of a network event through Xt function. This can be used to know the arrival of network event. How to register callback of RPC --- Phil's suggestion ?? (I have to review the tape) Approach Top down abstraction We have to decide this quickly. What interface is between applications of network components ? Describe services wanted. Decide whether they are achievable ? C++ stream is hopeful Bottom up low level issue Obejct access can be incorporated into inter-application messaging because an object is existing within an application. Media access and service access are assimilated now. We can use RPC for transfer of a large amount of data because NFS actually uses messaging of RPC not IPC. We decide what mechanism to be used within module, applicaition, across application. --- Yes. How to improve network interface from inter-application messaging to Object messaging ? Needs investigation Wish list expected for network interface Wish list expected for network interface ==RESUME=============================================================== ============================================================================== Summary of updated AM2 network interface ---------------------------------------- Services --------- 1)Service access. AM2 applications or users will benefit from servers(file server,media server, database server,etc.) residing in the network irrelevantly of its location, which are not AM2 processes in the network. Thus AM2 incorporates remote services and information, allowing for the distribution of multimedia resources. Conceivable servers for AM2 residing remotely as well as locally are media servers,database server, compute servers. 2)Media data access. Users can exchange any media from one station to another allowing for sharing images and work on it cooperatively or simultaneously. This might cause a problem of the network channel capacity when huge data is transferred over the network due to platform capacilty. Object access service is neccessary to fully-distributed authoring, but this capability will be implemented at a later version of AM2.0 3)Object access. AM2 objects or users can access easily any AM2 object on the network, including applications, servers dealing with special medium. The initialtor messages an AM2 entity (object) regardless of whether it is running locally or remotely. This enables applications or users on different machines to join the runtime interactively over the network. For example this enables two related AM2 applications to co-work by messaging to another object on the other side. Design policy ------------- We assume that AM2 applications, including special servers, are distributed in a closed local area network. This assumption comes from the reasons : (1) There are many cases in which distributed multimedia resources, including media itself, must be manipulated directly by human interruptions. (2) We need to investigate any arising problems in a small local area network before we go into a larger or connected network. (3) Initial AM2 applications will be targeted for use in a local area network. Also although we admit the need for the distributed object management mechanism, the first version of AM2 will not offer the full capabilities of inter-object messaging over a network. This mechanism will be introduced in a later version as the development of AM2 proceeds. The first AM2 networking capability will be limited to mainly inter-application messaging capability and a limited capability of inter-object messaging(for example, in the case of media exchange). AM2.0 must be designed to be easily extended to support inter-object messaging. Network Model ------------- AM2 applications will be distributed in an AM2 environment. In an AM2 environment applications requiring messaging to other applications will use the AM2 network service. AM2 messaging will be serviced by the AM2 networking service along with some other location service providers. These location service provider will consist of two managing classes of entities, a local location service entity on each host and a unique global location service entity on an AM2 environment. (Figure) Location Service Hierarchy -------------------------- (1)Local Location Service(LLS) This will deal with location inquiries within the same host domain. This will mainly deal with access points of target applications, e.g, a port in a Unix world. The most part of this software is dependent on platform- dependent services. If the Local Location Service cannot solve a inquiry, it will make a further inquiry to a Global Location Service. The resultant reply from this service will be stored locally into the Connection Management part of the Application Messaging Service. (2)Global Location Service(GLS) This will deal with location inquiries over an AM2 network. This mainly provide information about the host location of target applications. This service will reside separetely from AM2 authoring applications. Both of which will provide location in terms of applications. therefore there will be some other mechanism of localizing objects within an application. (3)Object Location Service(OLS) This will maintain information about objects within an application. This service and Object Location Service will be employed when a local object likes to message to a remote object within another application. This will be implemented at later versions of AM2. This service will be located within the same address space of an AM2 application. Network Layer Structure ----------------------- AM2 network interface will consist of several layers. Messaging mechanism will be devided into two parts to enhance its future extensibility to a real distributed object management envitonment as well as its easiness to construct stepwise. AM2.0 will have the capability of an AMS as the first prototype. The users of AM2 network interface can massage without knowing the actual location (address and port number) of the addressed peer. (Figure) (1)DIX(Device-independent) API This will absorb the differences between platform-dependent communication services and software above this layer must be the same among supported platforms. (2)Application Messaging Service(AMS) This will deliver messages to a target applications on a remote site as well as a local site. In this context, messaging granularity of objects is limited to applications including clients and servers. The destination of the message will be resolved by an AM2 local or global location service providers. This mechanism can be used in a traditional client-server or inter-application messaging. (3)Local Location Service(LLS) (The same as was described bofore) (4)API This layer will provide uniformed interfaces to AM2 network interface users (Application programs). (5)Object Messaging Service(OMS) This will deliver messages to any other objects within a given application regardless of their location. Granularity of the objects or messages is arbitrary depending on the application. This mechanism will be built upon the Application Messaging Service and Object Location Service. This will be implemented when AM2 is extended to distributed object environment in a later version. (6)Object Location Service(OLS) (The same as was described bofore) Network Classes Definition -------------------------- Within the Application Messaging Service, there will be a set of instances of a socket which are used in distributing messages. At least one pair of sockets consisting a local socket and a remote socket will be instantiated between messaging applications, one of which will play a role of a sender and the other a receiver. For example, messaging between a client and a server will need one pair of a sending and a receiving sockets. On the other hand, messaging between two AM2 applications might need two pairs of a sending and a receiving sockets because it might need duplex messaging. (In this context a "socket" doesn't mean the implementation of a Unix socket or a Macintosh socket but a platform- independent socket.) A socket will exist per one application. To allow interactions between applications a responding application must be registered or advertised at a Local Location Service boforehand. The instances of this class will be created on the request from either an application or an object in the Object messaging Service layer. The former will be inter-application messaging, whereas the latter will be inter-object messaging. There will need other classes in the Object Messaging Service layer which will seem to be similar to Senders and Receivers to define inter-object messaging. These object will create a Sender or a Receiver as a user of these objects and make a request to them. Sender class ------------ A sending application will have at least one Sender object because it must register or advertise its service access point with a Local Location Service with this socket. Methods Create Sender Delete Sender Register with Local Location Service Register with Global Location Service Connect to peer Send message to Local Location Service Send message to Global Location Service Send message to peer Ping to peer Get status of local peer Get status of remote peer . . . Receiver class -------------- A receiving application will have at least one Receiver object in accordance with its service access point so that it will be available to peers. Methods Create Receiver Delete Receiver Listen for incoming messages Register with Local Location Service Register with Grobal Location Service Add entry to advertised service list Delete entry from advertised service list Send dummy reply message Check incoming message . . . Messages -------- Messages will be classified into two categories, messages for AM2 network interface and for simple data transfer (application-dependent messages). Messages will be defined in terms of each method. AM2 Network Interface Protocols ------------------------------- DIX API ------- This will absorb the differences between platform-dependent communication services and software above this layer must be the same among supported platforms. The lower part of this software will be handled by RPC mechanism. Relevant problems here are as follows. Default protocol suite is TCP/IP and software bundled around it. (1)Protocol hiding DIX API must offer uniformed interfaces to software above it in a protocol- independent fashion though each protocol offers different user interfaces. (2)Data conversion DIX API will perform data conversion on messages to allow for communication among heterogenious hosts. (3)Network event handling To allow for asynchronous messaging as well as blocking or synchronous messaging, there must be some mechanism to handle network events in a asynchronous manner. This mechanism can be done through the help of platform-dependent system communication services along with RPC mechanism. Application Messaging Service(AMS) ---------------------------------- This will deliver messages to a target applications on a remote site as well as a local site. The destination of the message will be resolved by an AM2 local or global location service providers. The AMS will be devided into three parts, collections of Senders, Receivers and a Connection Management. The Connection Management will hold information about virtual circuits between the two communicating applications gained from the services by the Local Location Service. This layer will also be notified of incoming network event from the Network Event Handler in the DIX API layer. (Figure) Object Messaging Service(OMS) ----------------------------- This will deliver messages to any other objects within a given application regardless of their location. Granularity of the objects or messages is arbitrary depending on the application. This mechanism will be built upon the Application Messaging Service and Object Location Service. This will be implemented when AM2 is extended to distributed object environment in a later version. (1)If the target object is located in the same address space, this service simply will deliver a message to the object without delivering it to the p AMS. (2)If the target object is located in the same host but not in the same address space or in a remote host, this service will deliver a message to AMS but the message won`t go across the network. (3)If the target object is located remotely on the other host, this service will deliver a message to AMS and the message will go across the network to an opponent object. Underlying technologies ----------------------- Because the main target system of AM2 is a Unix system, underlying technologies on which AM2 network interface will be bulit are resulting as follows. AM2 network interface objects will be insulated from these underlying technologies by the DIX_API layer. Because TCP/IP is widely used in Unix and is now extending into in the PC, Macintsoh world, AM2 uses TCP/IP protocol as a system communication service. Although interprocess communications(IPC) is provided in many systems, it is truly realized in a platform-dependent fashion. Besides, writing a distributed application using IPC involves nasty details. To enhance the portability and of AM2, AM2 will use ONC RPC mechanism from Sun Microsystems. To allow AM2 applications to communicate between heterogeneous systems, AM2 uses one of standards, XDR(eXtenal Data Representationion.s, AM2 uses one of standards, XDR(eXtenal Data Representation) from Sun Microsystems. Porting policies ---------------- To enhance the portability of AM2 to those machines, DIX_API layers will absorb the platform differences among Unix workstations, PCs, Macintoshes, built upon DDX_API. ONC RPC mechanism which will be adopted in AM2 will isolate platform-dependency from these platforms. 1)PC The policy used to port AM2 into PCs is that an AM2 client, not server, applications are on PCs being provided services by server programs on Unix machines. This allows PCs to employ powerful computing power of Unix workstation. But fullly distributed network capability should be considered for Windows NT along with AM2 networking capabilities, which has a multitasking and inter-process communication mechanisms and networking capabilities. At present there is no urgent need for distributed computing for PCs. 2)Macintosh Distributed capabilities for Macintoshes will be offered by PC-NFS, but it capabilities are limited to a client-side. The policy used to port AM2 into Macintoshes is that AM2 client, not server, applications are on Macintoshes being provided services by server programs on Unix machines. This allows Macintoshes to employ powerful computing power of Unix workstation. The distributed processing among Macintoshes within Appletalk network means a big effort because of its characteristic of monolithic OS which supports single- tasking along with its network capabilities. This comes from a big difference between Macintosh's peer-to-peer massaging and Unix's client-server type messaging. Synchronous and asynchronous messaging -------------------------------------- To support for Window systems' event loop, AM2 network interface will support both synchronous and asynchrous messaging. The latter will be done through some lower level platform dependent IPC mechanisms below a window system(eg., socket of X-protocol).