Last update at http://inet.nttam.com : Thu May 4 12:36:16 1995 Multimedia Message Distribution in a Constrained Environment M S D Fernando - shantha@infolabs.is.lk W S Wijesoma - sardha@cse.mrt.ac.lk Gihan V. Dias - gihan@cse.mrt.ac.lk Abstract: Currently there are standards governing message handling, in particular MIME (Multipurpose Internet Mail Extensions)[1,2], for telecommuting mail messages encompassing a multitude of media, such as graphics images, voice data and motion video apart from plain text. However, the MIME standard (and also work in progress[3]) presupposes certain minimum technical capabilities amongst interconnected and participating mailservers for distribution of such multimedia mail. In particular, the interconnecting channels between mailservers should be of sufficient bandwidth to conduct the large amount of data in MIME messages at 'reasonable' rates and also the nodes must have adequate storage capacity for same. This requirement for bandwidth of channels and storage of mailservers for MIME capability prevents users connected to 'under-privileged' mail nodes from enjoying the benefits brought about by multi-media information and messaging. This may be in spite of the end users owning or having access to resource rich machines. In this paper a smart approach to routing of multi-media messages in an internetwork of mailservers, disparate in storage capacity, performance and network bandwidth, is presented. 1. Introduction: Currently, and most importantly in the future, there is a great need for gaining access to multi-media information. Therefore the Multi- purpose Internet Mail Extensions (MIME) facility is becoming popular due to its ability to present comprehensive messages which can be combinations of text, image, voice etc. At present, to gain access to such information, clients need to have high bandwidth links and high capacity (specifically storage) machines. If the link is a low speed one (e.g. most of dial-up links), then there are limitations such as long message transfer times leading to network traffic overheads, truncation of long messages due to message transfer agent (MTA) limitations etc. The need for high capacity machines is partly because there is no way to control people sending large messages. In addition, only those who have on-line Internet access can make full use of MIME due to its current design (e.g. MIME clients use FTP[4] in real-time to retrieve body-parts). While it is useful to have MIME capability, many people have the problem of receiving undesired messages. Use of MIME adds to the problem since MIME messages tend to be large and may be "difficult to process" (using locally available facilities). Hence a mechanism to control or manipulate such situations is needed. Considering such factors, many limited capacity users cannot, or are reluctant to use MIME, even though it is extremely useful. It is the objective of this paper to propose a mechanism which can be used to enable transfer of such multi-media messages taking into consideration the limitations and capabilities of the node requesting such message transfer and the link connecting to it. However most of the features presented are not limited to multi-media message transfer but can be applied for text based electronic mail messages as well. Additional features have been included to support sites where on-line message transfer cannot be done and hence some other transport mechanisms are used. 2. Concept: A network of mail nodes, although possibly connected in a mesh topology at a physical level, may be envisaged to form a 2-dimensional hierarchical structure from the perspective of mail routing viz., 1 - node capacity 2 - link capacity. The concept is therefore to offset the bandwidth and capacity limitations of a node at a specific level by requesting a mail node a step higher up to oblige to perform services on its behalf (which the former node is incapable of performing due to capacity or bandwidth limitations or self imposed restrictions). This is described as the Hierarchical Actions Transfer (HAT) concept. The service requests are known to the server through a specific configuration mechanism (described later). This could be achieved with manual intervention of the server administrator or automatically by processing the requests coming from the connected nodes. When delivering messages, the server will first look at the configuration of each connected node and the message delivery will take place accordingly. 2.1 Rationale Physically a mailserver or a gateway may be considered as a parent node for a certain sub-network but in the e-mail network, when taken as a whole, it is not so. A relay also is neither a child nor a parent when the whole network is considered. Therefore the concept "hierarchy" is not that suitable when physical connections in Internet are taken into account. However, in mail message transfer techniques, the concept of hierarchy does play a major role. Because, if the technological standard of a particular connection is considered, it cannot be of a better position in transferring messages with respect to the previous relays, mailservers, gateways, or with respect to the direction of message transfer, the reason being delays, unacceptable operations such as stripping off the message body parts, removing advanced or new message header lines, etc. are inevitable if all are not up-to standard relays/mailservers/gateways. Figure 1 illustrates the case where a message is originated from an arbitrary site A and goes to another site E of which the capacities of link and node are unknown to the originator. With respect to the effects caused while the mail is being routed, it is assumed that mail nodes and the lines higher up the hierarchy possess more capacity, performance and bandwidth than those lower in the hierarchy. Since A is the originator it can be considered that logically it has a very high line capacity. This model is clearly seen if we look at the network of mail nodes from the perspective of less privileged mail sites (e.g. E). Indicated Vectors show where any downgrading occurs along the direction of the message path. Line Capacity /\ | | A (mail originator) | !\ <-------- C (mail server) | ! \ .../ /! | \!/ \ ... / / ! | \ .... / / \!/ | ...\../ / | / \ / | <------D \ / | / ! \ / | / ! B | / \!/ | E (mail recipient) |---------------------------------------------------> Node Capacity For example, consider the message being routed from A to E through B, C and D. E has to inform D about its limitations and service requests, then D to C and B to A. C does not need to do so since B does not have vectors shown in the diagram. Thus in formulating a strategy it was always kept in mind that message transfer is virtually hierarchical at least along the direction of message route for individual messages. Hence service-requests and restrictions are always from down stream and hence the Hierarchical Actions Transfer (HAT) concept. That is, a child node will specify the services required from the parent node to compensate for its limitations. 2.2 Standards and compatibility: It is believed (and rightly so) that the Internet is the prime medium for interchange of messages and MIME will be a widely used standard for interchange of multimedia messages on the Internet. In keeping with this the design of the mechanism for routing of multimedia messages is based on MIME compliant mail handlers, transport mechanisms and the MIME format[2]. 3. Design: There are three major aspects to the design viz., extending the MIME compliant mail handlers and transport mechanisms at the mail nodes, appropriate handling of MIME messages/body-parts of different types, and a specification of capabilities and limitations of child nodes attached to parent nodes. The last aspect is central to the design as it involves specifying and enumerating the various restrictions, self imposed or otherwise, of a recipient (child) mail node to the parent mail node. This information, which is implemented as a flat ASCII file(similar to mailcap for MUAs[6]), called the ACTIONS FILE, forms the basis for selective routing of messages by the mail transport of the parent node to the child node. For every parent and child node pair such an information file has to be maintained at the parent mail nodes. That is to say, except at the leaf mail nodes of the network, all other internal mail nodes shall be required to maintain such databases. 3.1 Definitions: For the purposes of the design of a MIME mail routing and delivery system in constrained environments, mail sites are categorized into two classes: Low-capacity sites: Sites with communication links of low speeds when compared with currently available popular communication speeds, or with limited storage but have on-line Internet facilities (i.e. real time but low band- width or limited storage). Off-Internet sites: On-line Internet services (Gopher, 3W, etc.) or facilities such as ftp access are not provided or not available. However access to electronic mail is possible through a) dial-up lines b) non-dial-up media, such as using diskettes, tapes, etc. 4. Implementation To provide needed features we augment a mail server to perform some gateway functions. However it does not perform any major transformations to the messages, but there will be some minor alterations in message header contents while conforming to the Internet and MIME message header formats [2] and [5], and thus performing some gateway actions. On the other hand, it is possible to implement this in any relay, mail server or gateway and certain design features are significant only for relays and mail servers. Thus herein after it will be referred to as a server for convenience. As mentioned above, a nodes at a lower level will inform its immediate higher level node (server) about its limitations and services required. Then, when routing messages, relevant actions will be taken by the higher level node (server) on behalf of the immediate lower level node. However, it will affect all the nodes down-stream, and not vice- versa, hence the name HAT (Hierarchical Actions Transfer) concept. 4.1 Defining mail node restrictions and capabilities A server, for the purposes of adaptive mail routing, can broadly categorize mail nodes according to the degree of Internet connectivity and capacity of each, into one of the following: (1) high speed link with full Internet facilities (HS) (2) low speed link or low capacity site with full Internet facilities (LS) (3) off-Internet facilities: a. dial-up (DU) b. non-dial-up (ND) Note: there isn't any definite definition for low-speed connections since it depends on the currently available speeds, i.e. it is relative to existing technology. Thus, an existing high speed link may become a low speed link in future if it is not upgraded with the advancement of technology. The above node categories define a set of default services, or options, that are permitted at each server node. If a particular node is of type HS, it is assumed that it can handle MIME messages without any restrictions, and hence all the messages destined for that particular node is routed without performing any special action on the message. This mode is used as the default for any node, unless otherwise specifically declared as any of the other node types. The exact definitions and capabilities of other types of default node categories and their declarations are detailed in the subsequent sections. As is given in later sections, provision is also made for defining categories of nodes according to user preferences, and these node categories are referred to as "user-defined" nodes. 4.2 ACTIONS File: The key to Manipulate Message Delivery This is the most important file which defines characteristics, preferences, and category of the nodes attached to the mailserver. This file is to be used by the server implementation to get information such as the capabilities and restrictions of attached nodes. This will define whether each node is HS, LS, DU, ND or any user defined node category, and for each node what restrictions are applicable, what the server has to do on behalf of them, etc. ---------------------------------------------------------------------- Options under consideration Mnemonic Does not apply to ---------------------------------------------------------------------- Do ftp on my behalf FTP Send immediately SIM ND Send as a partial message SPM ND(1) Keep in data base for later retrieval KDB ND(1) Expire after n days ( n=3 default ) EXn Send abstract SAB Do not send ( Discard ) DIS Courier CUR Send a print out PRN Send as a FAX FAX --------------------------------------------------------------------- Table 1 : List of options for configuration of a nod ------------------ (1) This option is not directly applicable for ND Modifications or additions to this file are done by server administrator or automatically as described under section 5. At a site, initially, there may not be an ACTIONS file, however, once a request is made the server creates one automatically, or else it can be created manually, depending on how it is configured. Table 1 gives a list of useful options that one may wish to implement to configure a node attached to a server using the ACTIONS file. These options cater only for current requirements as perceived by the authors, and hence anyone may suggest more options in future. The above mnemonics will hereafter be used as reserved words in this paper. Brief descriptions of above options are given below: FTP: By default this service is offered by the server for DU and ND nodes. If a particular node does not have ftp facility or it is expensive for that node then it can ask the server to do that service on that node's behalf if a message with "Content-type: External-body; Access-type: ftp/tftp/anon- ftp"[7,4] comes. However, this will be successful only if the server is permitted to do so from the specified ftp site. If the server is unable to get the file it will notify the node. If it was a success, the server will keep it in a data-base location which has been specified in the original message header sent to the node. Parameters such as "server", "name" etc. that come under "Message/External-body:" Content-Type would give such information to the node. Therefore the node can easily get the body part that has been ftp'ied. When someone else need the same file an information file maintained for the use of KDB option would help the server to decide whether it is cached in its local data-base[13]. See also EXn. SIM: This is the default for LS and does not apply to ND. For DU it makes sense only if that node is set in slave mode to answer incoming connections (e.g. in UUCP, -r0 option) and the server is given permission to dial out immediately under certain conditions. However, during this type of a connection, the server will not be allowed to transfer all the other messages that are queued. SPM: This can be used if a particular node is unable to handle e-mail messages of high volumes. This may be avoided in case of ND since it does not use normal communication methods and it will depend on the implementation of courier method. The main idea is to use "Message/Partial" mechanism so that the nodes whose transport mechanism cannot support larger messages could be facilitated. However this will become somewhat complicated when a message is already fragmented and a re-fragmentation is needed. In this case the server will have to wait till all the fragments arrive at the server[8]. KDB: This can be used for later retrieval of huge but important e-mail messages or body parts of them. Messages or body parts of messages kept in data base are sent only if a subsequent request is made. For ND this will be of less importance since there are no immediate transfers anyway. The files downloaded by FTP will be kept in the data-base by default if it is a DU or ND node. If some condition is set in ACTIONS for FTP then only those files are downloaded. To keep other messages, those conditions have to be given following KDB as shown in Listing 2. Then the node will be able to get those saved messages before the expiration, since an abstract is sent to the node and the node is able to specify how the message should be sent (i.e. whether by courier, postal mail, etc.). The server will be maintaining an information file about the data base so that when a node requests a file from it, the server is able to validate the request. (For details reader is referred to [13].) See also EXn and SAB. EXn: This option is valid only if FTP or KDB is set. 'n' can be any integer and it denotes the expire duration for messages kept in data base. Default is three days. The server can run a separate process to rid files exceeding expiry dates. SAB: This is implied if KDB is specified and the abstract will give a brief description of what is kept in the data base. Therefore in case of KDB it is not necessary to specify this and the server should anyway send an abstract. However for DIS and CUR options set for LS and DU nodes, this can be used. Also for ND, with DIS option this will be useful. Once the abstract is sent in KDB option, the node may decide on the next action to be taken regarding that message. For example, if the message is huge but important then it might ask the server to send that through courier. DIS: If messages of a particular condition is not wanted this can be used to discard them and it is possible to incorporate SAB to get an abstract of what is discarded. Once a message is discarded, that will be notified to the originator. CUR: This is the default for type ND, and LS and DU also can use this to retrieve not-urgent and/or huge messages. It is also possible to incorporate SAB option with CUR in case the node needs to get an abstract without getting late. The options prevailing today are sending messages in diskettes or tapes. The specifications for transferring messages to magnetic media is a separate subject and it is not addressed in this paper though it is required in the implementation. PRN: This is used to get the messages in printed form (hard copy) instead of the usual message transfer. This can be used where postal services are offered. The output is somewhat restricted since no audio and video capability is supported. FAX: The messages are routed through a FAX gateway. It may be in the server or in some other machine. Output is restricted to formulated text and graphics images. 5.4 Default and user-defined Node Categories: As mentioned earlier, there are default node categories, namely HS, LS DU and ND and also user defined node categories. Now we may define the various categories of nodes fully in terms of the ACTIONS file declarations. The default node categories can have options given in Table 2 attributed to them and the server implementation will have to take them into consideration. ---------------------------------------------------------------------- HS No options - hence no processing of messages LS FTP, SPM, KDB, DIS, PRN, FAX, CUR DU FTP, SPM, KDB, DIS, PRN, FAX, CUR, SIM ND FTP, SPM, KDB, DIS, PRN, FAX ---------------------------------------------------------------------- Table 2 : Default node categories However, if the server administrator wishes to have categories which would allow only a subset of the defaults, a file called NODECAT can define such restrictions for the said node. Listing 1 is an example of how this may be accomplished. Listing 2 is an example of an ACTIONS file and it gives an idea of how connected nodes could be facilitated by a server to overcome nodes' limitations. For the BNF notations for ACTIONS and NODECAT files the reader is referred to [13]. In a nutshell, NODECAT defines the node types and their allowed options, and ACTIONS file specifies the conditions for a particular option in a particular node. Basically, this condition may be anything from the header (including encoded words[9,10]) and several other factors[13]. -------------------------------------------------------------------- # # The following node category is not allowed to have SPM, KDB, DIS and SIM. DUstrange:FTP,FAX,PRN,CUR,EXn,SAB # # Nodes of the following category can receive only faxes and postal messages. # They do not have e-mail facility. NDfp:FAX,PRN # # The following category is for nodes that never runs in slave mode and # hence SIM is not allowed for them. DUonly:FTP,SPM,KDB,EXn,SAB,DIS,CUR,PRN,FAX # ---------------------------------------------------------------------- Listing 1 : An example NODECAT file ---------------------------------------------------------------------- # Low speed category node (LS) called 'iamslow' restricting # transfer of messages/message-body parts iamslow.slower.net:LS:y # Do not send if message is bigger than 10000 lines # or if it is of type video # but it needs an abstract if it is from the domain # cse.mrt.ac.lk =DIS-$L10000 OR "Content-Type: Video/*" |SAB-"From:*@cse.mrt.ac.lk # Audio messages or messages bigger than 200kB are to be # kept in store and will be retrieved later # If not they expire after 7 days =KDB-"Content-Type: audio*" OR $S200 -EX7 # # A dial-up link example dialme:DU # It doesn't have ftp facility. So do it on its behalf if # possible, provided it is from dear@friend.* =FTP-"From: dear@friend.*" # Images are huge. MTA can process only small files. # hence, send messages as Message/Partial subtype if it is # longer than 1000 lines. =SPM-"Content-Type: Image/*" AND $L1000 # If it is Video do not send as partial messages even. # Just send through diskettes and send an abstract for my # reference =CUR-"Content-Type: Video/*"-diskette|SAB-"Content-Type: Video/*" # Messages from dealings@business.org are business matters # and need them at the office as a FAX =FAX-"From: dealings@business.org"|94-1-611044 # Very recently some one started sending bogus messages # Discard all the messages sent by that person # This was set automatically when requested by "dialme" =DIS-"From: weird@test.xyz" # # A user defined type taken from NODECAT. # All body parts needing ftp'ing are to be ftp'ied since no # restrictions are imposed. However, automatic updating is not allowed stranger:DUstrange:n # SIM is not allowed but he has fax. So send important ones by FAX. =FAX-"From: *academic.edu"|94-01-611044 # Less important ones are sent by post as a print out =PRN-"From: *boast.com"|"My name, No. 69/7A, My Street,My City, My Country" ------------------------------------------------------------------------ Listing 2 : An example ACTIONS file 5. Implementation Issues: In this section is discussed some issues of interest in implementing the adaptive routing strategy in the server. Processing of the ACTIONS file should take place at the same time of spooling (i.e. while directing messages to various sites). If the strategy is to process messages once they are in a "ready to go out" format it is obvious that there is a chance of establishing a connection by/with a node and the messages getting transferred through some processing on them is to be done by the server. If there is a message for any node connected to the server or a message is routed to an unknown destination through a connected node to the server, then before directing the message, the server should see whether there is any entry in the ACTIONS file related to that particular node. If there is, then it should process the message header as briefly described below. If no entry is found it should consider it as "HS" and direct the message in the normal way. The major task will be to process the options given in ACTIONS file for a particular node while conforming to RFC-822[5] and RFC-1521[2]. For example if FTP is an option for a particular node and a message comes with the header as given below, it is the server's task to get the necessary body/body-part from the specified ftp site and keep it in the data base till the expiry date or till the node receives the body-part[11,2]. "Content-Type: Message/External-Body; Access-Type=ftp" However, at the same time server will have to change the header to have "Access-Type=mailserver". Since this is not recommended in the MIME standard, the server will have to first encapsulate the message[12,2] and then add a higher level header with this or implement some mechanism to allow the node to get the body at a later stage. Another task with some overhead would be to fragment the messages if SPM is specified. This will get more complicated if the message is already fragmented in which case the server will have to collect them, re- combine them and re-fragment according to the new fragmentation specifications. However the node which has constraints will be facilitated. The other services like CUR, FAX and PRN also would be smart where high capacity communication links or machines are not available or uneconomical or there are sites which have only very basic facilities for computing. We can consider this particular instance as an integration of electronic mail and postal mail (snail mail) and Fax etc. The existing Fax gateways are operated on the principle that the sender (originator) wants to send the e-mail as a Fax to the destination. However, here the difference is that the sender is not aware of the recipient's setup and the recipient is the one who says that he needs the message in the form of a Fax, print-out or magnetic media (tape or diskette by courier). KDB will be a smart option since the node gets an abstract and hence it can decide whether it should actually receive the message and if so in what way. Once bogus message sources are identified, nodes are able to stop them at the server by using DIS. By allowing automatic configuration of ACTIONS file the server administrator would not have to commit much time on it if the nodes are able to do it appropriately. However when automatic configuration is allowed the server has to be smart. It will have to provide templates to be filled by the node. Another issue is setting the priority order of the options for a particular node. This is partly the responsibility of the node. Therefore it will have to consider the old setup when a modification is done, specially if a new condition for message delivery is introduced. For an example, if DIS is specified for a particular condition and some other action is specified after that line for some other condition for the same node but both conditions are valid for the same message then the latter will be useless. Consider the following entry in ACTIONS file: iamslow:LS =DIS-"From:dontsend@abcde.com" =KDB-"Content-Type: audio/*"-EX7 If dontsend@abcde.com sends a message with header "Content_Type: audio/basic" then that will not be kept in the data-base. However, if the order of specification is reversed then messages from that address having "Content-Type: audio/*" will be kept in the data-base but other messages from the same person are discarded. Therefore it is important to have the options in the priority order. Thus the first option set for a particular node is given priority 1 and for the second 2 and so on. Therefore, in the example ACTIONS file given Listing 2, for the node "dialme", FTP has priority 1, SPM 2 and CUR 3 even though it is not specifically mentioned in the ACTIONS file. If an automatic request is made to have FAX-"...." at a priority level 3, then CUR goes to priority 4. The server cannot have fixed priority orders. For example, in the above illustration, the server cannot determine whether DIS should come after KDB because the requirement of the node may be to have DIS before KDB. However, SPM has a special meaning if it is at the 1st priority level. That is, the message is to be fragmented after going through the rest of the options in the ACTIONS file. For an example, it may be asked for the same message to keep in the data-base, discard, courier, etc. If it is to be kept in the data base, first it should be fragmented and kept as several messages. If it is to be couriered, then it may not be fragmented. 6. Conclusion: It is accepted that Multi-media message exchange is becoming essential. However, at the same time, not everyone has the capacity to adapt to this without the coordinated help of the messaging system as a whole. The MIME server implementation proposed by this paper is inevitably a service oriented strategy to relieve less-privileged messaging nodes. An added advantage of the approach is that it allows for the implementation of administrative policies for controlling traffic and congestion arising from MIME mail to a mailserver site and the level of MIME services made available to users connected to the site. Further, the technique also allows for the integration of conventional and primitive messaging mechanisms, such as postal mail, courier by diskettes/tapes, and facsimile, into the realm of electronic messaging. Although, the technique is proposed mainly for low-capacity mail environments, it is to be noted that it also allows a mail site, whether it be using state-of-the- art e-mail infrastructure today, to adapt itself to keep up with the rapidly evolving computer and communications technology, until it is time to replace the existing infrastructure. Reduction of transmission cost and network traffic are also advantages offered by physical delivery courier and by keeping messages in the server data-base. Reduction of the receipt of junk mail and irrelevant messages will make most people happy. It will not be difficult for a server to handle a large number of sites since the administration is de-centralized by allowing automatic updating. Incorporation of artificial intelligence features, which is a possible future enhancement will fully automate the system and make it smarter. Acknowledgments: We would like to thank Nathaniel Borenstein for his invaluable comments on the draft of [13]. References: [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992. [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993. [3] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Format of Internet Message Bodies", Internet Draft - , November, 1994. [4] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. [5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [6] Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC 1524, Bellcore, September 1993. [7] Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981. [8] Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992. [9] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993. [10] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992. [11] Sirbu, M., "Content-Type Header Field for Internet Messages", STD 11, RFC 1049, CMU, March 1988. [12] Rose, M., and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and NMA, January 1985. [13] Fernando MSD., "Adaptive Multi-Media Mail Server", Internal Report, Dept. of Computer Science & Engineering, University of Moratuwa, January 1995. Author Information: MSD Fernando is a graduate from the University of Moratuwa in Computer Science and Engineering and currently doing a research in Multi Media E-Mail in the same University while working as a Software Engineer at Information Laboratories (Pvt.) Ltd. His current interests are in the field of Internet Messaging and Communication Technologies. WS Wijesoma is presently a Senior Lecturer at the Dept. of Computer Science & Engineering of the University of Moratuwa. He received his B.Sc. Engineering Degree from the University of Moratuwa in 1983. After a short spell of one year working in the computer industry as a Customer Engineer, he joined the Dept. of Comp. Sci. & Eng. in the Uni. of Moratuwa in 1985. Thereafter he proceeded to Uni. of Cambridge, UK, and obtained his Ph.D. in Robotics and Automation. He is also a Chartered Engineer and a member of the British Computer Society. His research focuses on Robot control, data communication and networking. Gihan V. Dias is a Director of Information Laboratories (Pvt.) Ltd. and a Senior Lecturer at the Department of Computer Science & Engineering, University of Moratuwa. After graduating from the University of Moratuwa, he obtained an MS and Ph.D. in Computer Science from the University of California. His current interests are in the fields of Computer Networking and Distributed Computer & Information Systems.