Message-Id: <9211231949.AA11519@Athena.MIT.EDU>
To: aybee@Athena.MIT.EDU
Subject: Tomi's
Date: Mon, 23 Nov 92 14:52:00 -0500
From: Judson Harward <jud%ithake@ceci.mit.edu>


------- Forwarded Message

Return-Path: htomi
Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by ceci.mit.edu id AA17070g; Fri, 6 Nov 92 15:55:59 EST
Received: from NOBUNAGA.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA05993; Fri, 6 Nov 92 15:52:54 EST
Message-Id: <9211062052.AA05993@Athena.MIT.EDU>
Received: by ceci.mit.edu id AA00878g; Fri, 6 Nov 92 15:55:28 EST
Date: Fri, 6 Nov 92 15:55:28 EST
From: Tomi Tominaga <htomi>
To: jud@Athena.MIT.EDU, pbailey@athena.mit.ed, harada@Athena.MIT.EDU,
        mau@iesl.mit.edu, sigmund@hd.uib.no, htomi


Hi. 

I summarize the status of AM2 network interface. Thanks to Jud's and Adam's
suggestion I could clarify myself about the support for both inter-application
messaging and inter-object messaging in an improving manner. 
But I have to apologize the slow progress, because I always spend time on
investigation on something.

By the way I will leave my office because of dental appointment.
Have a nice weekend.

Tomi.

- -------------------------------------------------------------------------
(memo)

1)As for porting to Macintosh, I have not come to resolve this problem 
  yet.  Machintosh's peer-to-peer messaging of those and Unix's client-server 
  type messaging differ so much(for example,name binding method) especially 
  when used in an AppleTalk network. This applies to PCs.  So in this 
  design specification, I refer to the case where a Macintosh work only as 
  client without refering full porting implementation of Macintoshes ot PCs.

2)In case of media exchange, I think this is also a kind of messaging object 
  in a global sense. For exmaple, One user might request media data from a 
  remote media object or database interface object to be brought to his local 
  station. I have to clarify myself by exchanging the ideas of other objects
  with others in this matter. I am not sure the correctness of dealing this 
  problem as a inter-object messaging as well.

3)I continue to investingate RPC messaging. As for asynchronous messaging, 
  we have to go into the details of network i/o such level as socket,pipe,etc.
  to know the arrival of a network event and bring about the corresponding 
  callback. This can be done through an interval timer of Xt to poll the 
  incoming event. But I must further investigate because this is 
  platform-dependent.

4)RPC vs. IPC
  I plan to use RPC, not IPC because it hides platform dependencies 
  including system communication service and data representation conversion.
  I investigated NFS and it is implemented by RPC without using IPC.
  And I have not come to the problem when a RPC packet goes through a bridge.

  Mauricio, would you explain the problem again ?  We must be care about
  the network details when we use RPC as a programmer, not network manager
  (network setting) ?

  I plan to build media access methods by means of RPC now irrelevant of the 
  fact that ONC RPC and NCS RPC are not interoperable.  (I like this problem 
  to be solved by Sun and HP) 
  
5)I have not defined new network interface classes yet. I think I will make
  new classes instead of the old ones I proposed before, but not yet.


==============================================================================
Updated or added ideas about AM2 network interface 
- ---------------------------------------------------

Services
- ---------
In priority order.
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 network interface will consist of two parts so that it will fulfill its
functions. The main reason of deviding messaging mechanism into two parts
comes from 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 distributed messaging hub as the first prototype.
AM2 network interface user can massage without knowing the actual location of 
the addressed peer. 

1)Distributed messaging hub
This part handles messages to be sent to the other target applications on a 
remote site as well as a local site.  In this context, messaging granularity 
of objects or requests is limited to applications. The destination of the 
message will be resolved by some network mechanism(eg., name binding). 
This mechanism can be used in a traditional client-server or inter-application 
messaging.

2)Local messaging hub
This part handles messaging to be delivered to any other messaging entity
(object) within a local application domain.  Granularity of the objects or
messages is arbitrary depending on an application. This mechanism will build
upon the preceeding distributed messaging hub when AM2 is extended to a 
distributed object environment.  The destination of the message will be 
resolved by this local messaging hub if it is addressed locally. Otherwise 
the message will be delivered to the distributed messaging hub where the 
destination will be localized through the assistance of some network service.
This part will mainly comprise AM2 object management machanism with some 
supplementary mechanism in the future and this mechanism must be resolved.

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). 


END.


------- End of Forwarded Message