GB2426161A - Networking via a communication layer - Google Patents

Abstract

An inter-process communication layer (13, 17), lying between a physical layer (PHY), a TCP/IP stack (9, 11) and an application layer (15, 19), formats data according to a protocol which is independent of the delivery channel, allowing construction virtual networks of nodes either within a single computer running different local applications or between remote computers by invitation. The format has a data part and a mark up part providing display information. Cryptographic registration may be employed, and nodes communicate via a stateless request-response process through a transport layer.

Description

Interprocess Communication

Description

The present invention relates to interprocess communication between processes on the same or different computers.

It is known for processes on the same or different computers to communicated with each other. However, different communication mechanisms are used for communication between processes on the same computer and communication between processes on different computers.

According to the present invention, there is provided a data communication unit comprising: input means for receiving data to be transmitted and a destination address therefor; formatting means for formatting data from the input means according to a predetermined structure; transmission means for selectively sending formatted data via discrete local and remote delivery channels in dependence on the associated destination address; receiving means for receiving formatted data from said local and remote delivery channels; and extraction means for extracting the data from the formatted data received by the receiving means, wherein the formatting means is configured such that said predetermined structure is independent of delivery channel.

Preferably, the unit includes encryption means for encrypting formatted data before transmission thereof by the transmission means and decryption means for decrypting formatted data receiving by the receiving means.

Preferably, the formatting means is configured such that the data is formatted in a format having a data part and a mark up part providing display information associated with the data. More preferably, the formatting means is configured such that the data is also included in the mark up part.

According to the present invention, there is also provided a data communication network including a plurality of nodes, wherein each node comprises a unit according to the present invention, serving a respective processes, and pairs of nodes are linked by said local or remote delivery channels. A network formed in this way may be considered to be a virtual network because the topology of the nodes need not match a physical layer topology. At one extreme all of the nodes may be on one computer and at another extreme the nodes may be on respective different computers connected by a wide area network.

The network preferably has a registration service and each node is configured to register with the registration service. More preferably, each node is configured to send a respective public key of the private/public key pair and/or a network address and an ID, to the registration service during said registration.

Preferably, the network has a discovery service with access to information provided by nodes during registration with the registration service and each node is configured for requesting, from the discovery service, the network addresses and public keys of nodes not in the network.

The registration and discovery services may be provided at locations that are not part of the network. In this way, these services can be provided centrally to provide for ad-hoc formation of a plurality of networks.

Preferably, each node is configured for sending an invitation messages to external nodes, not in the network, in order to expand the network. Of course, invited nodes may decline an invitation.

Preferably, each node is configurable to have a master/client or peer-topeer relationship with another node. One node may have different relationships with different nodes so that networks with complex hybrid topologies can be formed.

Certain topologies may be particularly appropriate to particular distributed processing applications where the processing is distributed among nodes of a network according to the present invention.

Preferably, the nodes are configured to communicate with each other using a stateless request-response process. More preferably, the nodes are configured such that a transaction between two nodes can be effected by one request-response pair in which the transaction reply is carried in the response or by first and second request-response pair, initiated by respective nodes, in which the transaction reply is carried in the request of the second request-response pair. The choice of transaction mode can be made on the time required for a response to be generated.

Nodes may be configured to respond to a message with a response message including user interface defining data, e.g. mark up. In this case, one node may provide an externally accessible interface and be responsive to a request at said interface to: transmit messages to other nodes; receiving response messages, including user interface defining data, from said other nodes; aggregate said user interface defining data; and transmit the aggregated user interface defining data to the source of the request received at said interface.

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings, in which: Figure 1 shows a simple local area network; Figure 2 illustrates interprocess communication paths involving two of the computers Figure 1; Figure 3 shows a first virtual network embodying the present invention; Figure 4 is a dataflow diagram illustrating communication between two processes on the same computer; Figure 5 is a dataflow diagram illustrating communication between two processes on different computers; Figure 6 is a signalling diagram showing node registration in a system according to the present invention; Figure 7 is a signalling diagram showing node logging into a discovery service in a system according to the present invention; Figure 8 is a signalling diagram showing an invitation to a node to join a virtual network in a system according to the present invention with a discovery service; Figures 9 to 12 show virtual networks, embodying the present invention with different topologies; Figure 13 show a virtual network providing a distributed processing system; Figure 14 is a flowchart illustrating the operation of a distributed file search function provided by the network in Figure 13; and Figures 15 to 17 are flowchart illustrative processes in the formation and operation of an aggregated file system using a virtual network according to the present invention.

A simple local area network (LAN) will be used to explain the present invention.

However, it is to be understood that the physical network layer is transparent to the present invention and that processes may communicate according to the present invention over any form or extent of network.

Referring to Figure 1, a simple LAN comprises first, second and third computers 1, 3, 5 interconnected by a hub 7.

Referring to Figure 2, the first and second computers 1, 3 can communicate with each other using respective TCP/IP stacks 9, 11. In the first computer 1, an interprocess communication layer 13 is implemented above its TCP/IP stack 9 and below an application layer 15. A similar interprocess communication layer 17 is implemented in the second computer 3 between its TCP/IP stack 11 and an application layer 19.

First and second processes 15a, 15b in the first computer's application layer 15 can communicate with each other via the first computer's interprocess communication layer 13. Third and fourth processes 19a, 19b in the second computer's application layer 19 can communicate with each other via the second computer's interprocess communication layer 17. The first and second processes 15a, 15b can also communicate with the third and fourth processes, and vice versa. In these cases, the communication is routed down through one interprocess communication layer 13, 17 to the underlying TCP/IP stack 9, 11 which routes it to the destination computer. When the communication is received by the destination computer, it is passed up the receiving TCP/IP stack 9, 11 to the overlying interprocess communication layer 13, 17 which then routes it to the destination process 15a, 15b, 19a, 19b.

The third computer 5 is similarly configured and a processes on the third computer can communicate with processes 15a, 15b, 19a, 19b on the first and second computers 1, 3.

By means of the interprocess communication layer 13, 17, the processes 15a, 15b, 19a, 19b can also make operating system resources 21, 23, such as the clipboard, file locking, memory management and messages, e.g. GUI event messages, available to each other.

For the purposes of the present explanation, the term "operating system" is intended to include discrete desktop environments, such as CDE, KDE or Gnome, as well as systems in which the desktop environment is an integrated component of the operating system proper, as in the case of various Windows operating systems.

When an application is being developed to make use of the interprocess communication layer 13, 17, the application can be statically or dynamically linked at compile time to a library providing the interprocess communication layer functionality. A special case of static linking is the inclusion of a "component", such as the skilled reader will be familiar with from Borland's Delphi language.

The interprocess communications layer functionality can also be provided in the form of a COM objects for the Windows platform or equivalent elements of other systems, e.g. Gnome's bonobo and Sun Microsystems's UNO. Providing the interprocess communication layer functionality in this way, makes it available to pre-exisiting application, such as spreadsheets and word processors, via their own internal scripting languages.

Referring to Figure 3, the processes 15a, 15b, 19a, 19b of applications written to make use of the interprocess communication layer form first to fourth nodes 51, 52, 53, 54 of a virtual network 50, by means of their associated senders and listeners.

The first and second processes 15a, 15b are on the first computer 1, and the third and fourth processes 19a, 19b are on the second computer 3. A server 55 provides registration and discovery services, which will be described in more detail below.

The server 55 is not a member of the virtual network 50 and has a solely administrative function for the virtual network 50 and other virtual networks (not shown).

The virtual network 50 corresponds to the interprocess communication layers 17, 19 and may reside wholly within one computer. However, there could be one node per computer of a physical network or variable numbers of nodes implemented in different computers of a physical network. In the present example, the physical networking protocol is TCP/IP. However, other protocols, for example IPX or WDP (Wireless Data Protocol) could be used. Indeed, the physical networking should be invisible to a virtual network 50 according to the present invention.

Each node 51, 52, 53, 54 in the virtual network can potentially accept messages from every other node 51, 52, 53, 54 in the virtual network. However, as explained below the active topology of the virtual network is configurable.

The format of the interprocess messages, used in the present example, will now be explained. Interprocess messaging comprises transactions which comprises a request message and a response message. The transport for the transactions is itself request-response based. However, a transaction may be completed with one transport layer request-response session or two transport layer request-response sessions, one initiated from each end of the transaction.

A request message, which is carried in a transport layer request, comprises: POST /AS HTITP/1.1 User-Agent: AS Host: (hostname) ContentType: text/xml; charset-utf-8 Content-Length: (length of content in bytes) SOAPActjon: /AS <?xml version"l.O"?> <Envelope> <Body> <convcrsatjonjd>Convld< /conversatjonjd> <id>sender's name</id> <EncryptedData> encrypted information </EncryptedData> </Body> </Envelope> Convld is a globally unique identifier.

The encrypted information in its plain text form is as follows: <ASMessage> <command>cmd< /command> MessageParams </ASMes sage> MessageParams is variable document fragment, for example: <user> sender's name </user> <text> Conversation text to display </text> <forward> list of users to forward to </ forward> A response message, which may be carried in a transport layer response or a subsequent transport layer reply, comprises: HTTP/1.1 ResponseNo ResponseText Content-Type: text/xml; charset-utf-8 Content- Length: (length of content in bytes) Server: AS 1.0 <Envelope> <Body> <conversationld>Convld< /conversatjonjd> <EncryptedData> encrypted information </EncryptedData> </Body> </Envelope> Convld is a globally unique identifier.

The encrypted information in its plain text form is as follows: <ASMessageResponse> MessageResponse </A5MessageRcsponse> MessageResponse is variable variable document fragment whose content depends on the command being responded to, for example: <result>OK</result> However, the MessageResponse may be a document fragment containing data and display parts, e.g. <result> <data> 15 </data> <display> <mark up> CDATA containing HTML, XML </markup> <stylesheet> XSL, css </stylesheet> <hash> hash of mark up and stylesheet parts </hash> </display> </result> The communication between processes will now be described.

Referring to Figure 4, a process I 5a, I 5b implementing the present invention, will instantiate a listener process 33, 35. The listener process 33, 35 listens for incoming messages from the TCP/IP stack 9, 11, i.e. messages using TCP/IP as the transport, and instances of a data received event from a COM server 41, implementing the present invention, on the same computer. The event indicates that a message is waiting to be read from COM server 41 and identifies the target process.

When a first process 1 5a wishes to communicate with a second process I 5b on the same computer, it performs a send process 39. The send process 39 formats the message and determines whether the destination process 37 is on the same computer or on remote computer. As the destination process 37 is on the same computer, the send process 39 calls an method of the COM server 41, passing a - 10 - request message as a parameter of the call. This causes the GUM server 41 to generate the data received event 42.

The listener process 33 of the second, destination process I 5b, receives the event and, if it is the target, spawns a thread to call method of the GUM server 41 to read the request message from the GUM server 41. The newly spawned thread then passes the request message to the second process 15b.

The second process 15b responds to the request message by performing a send process 43 to send a response message to the first process iSa. The response message may contain a full response to the request message, e.g. a function call return value as the message payload, or an acknowledgement of receipt that will be followed by a full response later, in what is formally a request message. The case of an immediate definitive response will be termed "synchronous" and the case of an acknowledgement response followed a definitive response in a request message will be termed "asynchronous".

The send process 43 of the second process 15b call a method of the GUM server 41, passing the response message as a parameter, and then the GUM server 41 generates a data received event. The event is detected by listener process 35 of the first process 15a. The listener process 35 of the first process 15a then spawns a thread to obtain the response message by calling a method of the CUM server 41.

The obtained response is passed to the first process 15a.

If the communication is asynchronous, the second process 15b will subsequently send a request message, carrying the response as PUST data, to the first process 15a using the same process as described above for the initial request. The first process 151) will respond to the request message, carrying the PUST data, with a simple acknowledgement response.

Referring to Figure 5, when a first process I 5a wishes to communicate with a third process 19a on a different computer, it performs its send process 39. The send process 39 formats the message and determines whether the destination process 37 -11 - is on the same computer or remote. As the destination process 19a is on a different computer, the send process 39 transmits a request message across the network 45, using TCP/IP as the transport.

The listener process 38 of the third, destination process 19a spawns a thread to receive the request message from the network 45. The newly spawned thread then passes the request message to the third process 19a.

The third process 19a responds to the request message by performing a send process 44 to send a synchronous or asynchronous response message, as described above, to the first process ISa.

The listener process 35 of the first process 15a spawns a thread to read the response message from the network 45 and pass it to the first process 15a.

If the communication is asynchronous, the third process 19a will subsequently send a request message, carrying the response as POST data, to the first process 15a via the network 44. The first application 31 will respond to this request message with a simple acknowledgement response.

Referring again to Figure 3, the first to fourth nodes 51, 52, 53, 54 are configurable and their roles and functioning can be set by setting various parameters at runtime.

These parameters include the mode of the node, i.e. standalone, master, slave, slave, peer or peer (chain), the network address, e.g. ip address or fully qualified domain name, which of two ports is to be used, and a unique name for the node. These parameters may be stored in the Registry on Windows systems or in configuration files on other systems. Each node 51, 52, 53, 54 also maintains a list of the other nodes 51, 52, 53, 54 of which it is aware.

The server 55 provides registration and discovery services, implemented using web service, to the nodes 51, 52, 53, 54.

- 12 - The registration service is used to "activate" a node so that it may form part of a virtual network. Before activation, a node cannot make direct contact with other nodes to form a network.

Each of the first to fourth nodes 51, 52, 53, 54 has a unique ID.

Referring to Figure 6, when a node, e.g. the first node 51, is first created, it generates a public-private RSA key pair and sends a registration SOAP request to the server 55. The request includes the node's unique ID and its public key.

The server 55 adds the unique identifier and the public key to a database which may be, for example, an SQL database or an LDAP repository. The request is then acknowledged with a response.

The discovery service tracks the online presence of nodes and provides information so that nodes may initiate connections with each other to form networks.

It should be borne in mind at this point that in the following, communication between nodes is as described above with reference to Figures 4 and 5.

Referring to Figure 7, each time a node, e.g. the first node 51, is started up, it logs into the discovery service, provided by the server 55, to provide information about its status. The node 51 sends a login request to the discovery service which responds with login successful or login unsuccessful responses as appropriate.

The login request message indicates whether the node 51 is a messagereceive- capable node (i.e. it is not prevented from being the destination of a message by a packet filtering, network address translation or some other firewall function) or a message-receive-incapable node (i.e. it is not prevented from being the destination of a message by a packet filtering, network address translation or some other firewall function), its current network address, port and other information.

- 13 - Access to virtual networks is on the invitation principle. A virtual network is initiated by one node sending an invitation to another node which may then accept or decline the invitation. Once a network has been created, additional nodes may be invited to join it by the member nodes.

Referring to Figure 8, when, for example, the first node 51 invites the second node 52 to join a network, the first node 51 sends a lookup request to the discovery server, provided by the fifth node 55. The lookup request includes the unique id of the second node 51.

When the discovery server receives the lookup request, it determines whether a node having the transmitted unique id exists, is permitted to communicate with the first node 51 and is active. If not all of these conditions are met, a lookup exception response is sent back to the first node 51.

If all of the conditions are met, the lookup response message contains the public key of the second node 52 and its network address and port.

After receiving the successful lookup response message, the first node 51 sends an invitation message to the second node 52, encrypted with the second node's public key. The invitation includes the mode, slave, peer or peer (chain), in which the second node 52 is to operate in relation to the first node 51. If the first node is in master mode, the second node 52 will be invited to become a slave. If the first node 51 is in a peer mode, the second node 52 will be invited to join in the same mode.

The second node 52 should then reply with an acknowledgement message and the two nodes 51, 52 then negotiate a symmetric key for encrypting subsequent messages.

The master, slave, peer and peer (chain) modes enable networks having different topologies to be established.

- 14 - Referring to Figure 9, in a first topology, the first node 51 is in master mode and the second, third and fourth nodes 52, 53, 54 are all in slave mode. The slave nodes 52, 53, 54 provide services to the master node 51. However, the master node 51 does not provide services to the slave node 52, 53, 54. In other words, interactions between the master node 51 and any slave node 52, 53, 54 are always initiated by the master node 51.

This topology is created by the first node 51 inviting each of the second to fourth nodes 52, 53, 54 to join, obtaining their public keys and network addresses from the server 55 to do so.

Referring to Figure 10, in a second topology, all of the first to fourth nodes 51, 52, 53, 54 are in peer mode and make services available to each other mutually.

A peer-to-peer network like that in Figure 10 can be built in a distributed manner.

For example, the first node 51 might invite the second and third nodes 52, 53 to join the network and then the second node 52 might invite the fourth node 54 to join the network.

Referring to Figure 11, in a third topology, the first to fourth nodes 51, 52, 53, 54 are in peer (chain) mode. Thus, each of the first to fourth nodes 51, 52, 53, 54 can request services from and provide services to the nodes on either side of it in a ring.

Thus, the first node 51 interacts with the second and fourth nodes 52, 54, the second node 52 interacts with the first and third nodes 51, 53, the third node 53 interacts with the second and fourth nodes 52, 54 and the fourth node 54 interacts with the third and first nodes 53, 51.

This topology is created by first node 51 first inviting the second node 52 to join the network. The invitation message includes the node between which the invited node is to insert itself. The invited node then sends messages to its neighbours to inform them of the topology change. Thus, in the present case, the second node 52 will send to messages to the first node 51, informing it that it is now to the left and to the right of it respectively.

- 15 - The first node 51 may now expand the network by inviting the third node 53 to insert itself between the first and second nodes 51, 52. This will cause the third node 53 to send messages to the first and second nodes 51, 52 informing them of the topology change.

Finally, by way of example, the second node 52 invites the fourth node 54 to join between the third and first nodes 53, 51. The fourth node 54 will then inform the first and third nodes 51, 53 of the topology changes.

It the chain is open ended, nodes may simply be appended to the chain, although they may be inserted by the method described above.

Referring to Figure 12, in a fourth, hybrid topology, the first node 51 is in master mode, the second and fourth nodes 52, 54 are in slave/peer mode and the third node 53 is in peer (chain) mode. Thus, the master node 51 can obtain services from the second and fourth nodes 52, 54 but does not provide services itself. The second and fourth nodes 52, 54 will provide services to any other node and the third node 53 can obtain services from the second and fourth nodes 52, 54 and will only provide services to the second and fourth nodes 52, 54.

This topology can be created, by way of illustration, by the first node 51 inviting the second and fourth nodes 52, 54 to join the network as slaves, the second node 52 invites the fourth node 54 to join with it in peer mode and the fourth node 54 invites the third node 53 to join between the second and fourth nodes 52, 54 in peer (chain) mode.

Referring to Figure 13, a distributed processing system is implemented across a master-slave distributed network, as shown in Figure 9. All internode communication is encrypted. The first node 51 implements an externally accessible http server 61. A user can interact with the http server 61 across a physical network 62 from a remote computer 63 using a web browser 64.

- 16 - Each of the second to fourth nodes 52, 53, 54 comprises a file searching application. It should be born in mind that one of more of the second to fourth nodes 52, 53, 54 may actually be running on the same machine as the first node 51.

The use of the distributed file searching application with a web browser will now be described.

Referring to Figure 14, the user sends a request for a file search page from the web browser 64 to the http server 61 (step si). The http server 61 wraps the document part of the URL in a request message of the type described above and sends this message to each of the second to fourth nodes 52, 53, 54 (step s2). Each of these nodes responds synchronously with a response message including a display part containing HTML for a search criteria form (step s3). The HTML contents of the responses are compared by comparing their hashes and, since they are the same in this case, the HTML from one of the responses is used to create an HTML form page with is sent to the web browser 64 (step s4).

When the HTML document has been received, it is displayed by the web browser 64 (step s5). The user specifies the search criteria and clicks on a submit button (step s6). Clicking on the submit button causes the web browser 64 to send a request to the http server 61 which includes the search criteria.

The http server 61 encapsulated the http request form data in a search request message that it sends to the second to fourth nodes 52, 53, 54 (step s7).

The second to fourth nodes 52, 53, 54 perform their search functions and respond with response messages including HTML defining tables listing the documents, if any, meeting the user's criteria (step s8). The response messages are provided asynchronously in this case.

When the response messages have all been received by the first node 51, it determines that they are all different by comparing their digests (step s9) and, consequently, concatenates the HTML from the response messages and embeds the - 17 - result in some boiler plate HTML to create a results page (step slO). The results page is then sent by the http server 61 (step sI 1) as the response to the search request from the web browser 64, which then displays it to the user (step s12).

From the above, it can be seen that the http server 61 is application agnostic because the second to fourth nodes 52, 53, 54 are responsible for creating the web pages viewed by the user except the unchanging elements.

In the above example, the request from the web browser is in respect ofall of the second to fourth nodes 52, 53, 54. However, the http server 61 is responsive to form data identifying a subset of the second to fourth nodes 52, 53, 54 so that the request from the web browser is only passed on to the identified nodes.

It will be appreciated that a custom client-server system, connecting the remote computer 63 and the first node 51, may be created. This system would use the same messages across the virtual network. However, the raw data parts would be used rather than the mark up parts.

A network file system in a peer-to-peer network, as shown in Figure 10, will now be described. It is to be understood that the nodes will communicate with the registrations and discovery services provided by the fifth node 55 as described above and all communication will be encrypted as described above.

Referring again to Figure 10, in this example, each of the first to fourth nodes 51, 25..., 54 is implemented on a computer running a Windows operating system. Each of these nodes 51, ..., 54 interfaces with the Windows operating system as a "narnespace", i.e. as a virtual file system. In other words, each node 51, ..., 54 provides implementations of the basic file system operations, e. g.. create, delete, open, close, copy and move.

Referring to Figure 15, when the first node 51 is created, it creates a folder in the local file system (step s21). This folder appears in Explorer and an option "Add - 18- Node" appears in the pop up menu that appears when the user right-clicks on the folder in Explorer.

Referring to Figure 16, when the "Add Node" option is selected, the first node 51 presents the user with a dialog box into which the user can enter the unique ID of the node to be added (step s31). Alternatively, the dialog box could allow the user to browser the discovery service on the server 55.

Once the user has selected the new node, for example the second node 52, the first node 51 invites the second node 52 to join it in a virtual network (step s32). If the second node 52 is successfully joined to the virtual network, the first node 51 sends an initialisation message to the second node 52 (step s33), which includes the ids of any other nodes in the virtual network. The second node 52 responds to the initialisation message by creating a folder in the local file system and sending a confirmation response back to the first node (step s34).

After initialisation, second node 52 then sends a file list request to each other node in the network, in this case only the first node 51, which respond asynchronously with messages listing the files and folders in folder being shared (step s35). The other nodes are also triggered to send file list requests to the new node, i.e. in this case, the first node 51 sends a file list request to the second node 51. In this way, the file system information held by the nodes is synchronised.

When the file system information is synchronised, each node 51, 52 presents the aggregated contents of the shared folders as the contents of one folder to the local operating system.

The third and fourth nodes 53, 54 are added similarly in response to requests from an existing member node.

The maintenance of the synchronisation of the file system information is event driven. That is, if there is a change in state of a file system entity, the node at which the entity is physically located, sends a state change message to each of the other - 19 - nodes in the virtual network, for example the message may indicate that a file has become locked or has been deleted.

The folders initially created by the first to fourth nodes 51, ..., 54 form one logical folder as far as the operating systems of the computer running the nodes 51,..., 54.

From the user's perspective, this logical folder can be interacted with just like physical folder in the local file system.

Referring to Figure 17, if a user wants to edit a file in the logical folder, the user's editing program calls an operating system file open function which causes the operating system to call the file open implementation provided by the local node 51, 54 (step s41). If the file is stored locally (step s42), the node returns a handle for the file (step s43) and sends a file locked message to the other nodes (step s44).

If the file is not stored locally (step s42), the node sends a file open request message to the node holding the file which responds with a copy of the file (step s45). The node, holding the file, locks the file in its local file system and sends a file locked message to the other nodes.

The node, requesting the file, stores the copy of the file in a temporary location (step s46) and returns a handle to the copy file to the editing application (step s47).

If the user commits changes to the file, a copy of the edited file is sent to the node from where it originated, which updates it copy of the file. When the file is closed, the owning node is informed and send messages notifying the other nodes the file lock has been removed.

It can thus be seen that file operations are either processed locally by nodes in a conventional manner or by means of messaging between nodes. However, this is invisible to the user.

It will be appreciated that the aggregated file system may be implemented without the messages notifying entity state changes. Instead, information that a file is locked may be provided as an exception response to a file write message.

-

Furthermore, the nodes need not maintain synchronised file list information.

Instead, a file list request to a node from its local operating system may trigger the node to request file lists from all of the other nodes and then aggregate them with the local file system information.

It will be appreciated that so long as the nodes interface correctly with their local file systems, the files in the aggregated file system can be physically stored in a variety of forms, e.g. in databases or webDAV file systems.

The virtual network architecture according to the present invention will provide the foundation for numerous collaborative and networked applications. Furthermore, many modifications may be made to the embodiments described above, for example in the format of the messages and the details of the registration and discovery services. The registration and discovery services could themselves be implemented in a distributed manner over a virtual network according to the present invention.

Claims (15)

1. - 21 - Claims 1. A data communication unit comprising: input means for

   receiving data to be transmitted and a destination address therefor; formatting means for formatting data from the input means according to a predetermined structure; transmission means for selectively sending formatted data via discrete local and remote delivery channels in dependence on the associated destination address; receiving means for receiving formatted data from said local and remote delivery channels; and extraction means for extracting the data from the formatted data received by the receiving means, wherein the formatting means is configured such that said predetermined structure is independent of delivery channel.
2. 2. A unit according to claim 1, including encryption means for encrypting formatted data before transmission thereof by the transmission means and decryption means for decrypting formatted data receiving by the receiving means.
3. 3. A unit according to claim I or 2, wherein the formatting means is configured such that the data is formatted in a format having a data part and a mark up part providing display information associated with the data.
4. 4. A unit according to claim 3, wherein the formatting means is configured such that the data is also included in the mark up part.
5. 5. A data communication network including a plurality of nodes, wherein each node comprises a unit according to claim I or 2, serving a respective processes, and pairs of nodes are linked by said local or remote delivery channels.
6. 6. A network according to claim 5, having a registration service, wherein each node is configured to register with the registration service.

   - 22 -
7. 7. A network according to claim 6, wherein each node is configured to send a respective public key of the private/public key pair, to the registration service during said registration.
8. 8. A network according to claim 6 or 7, wherein each node is configured to send a network address and an ID to the registration service during registration.
9. 9. A network according to any one of claims 5 to 8, having a discovery service with access to information provided by nodes during registration with the registration service, wherein each node is configured for requesting, from the discovery service, the network addresses and public keys of nodes not in the network.
10. 10. A network according to any one of claims 5 to 9, wherein each node is configured for sending an invitation messages to external nodes, not in the network, in order to expand the network.
11. 11. A network according to any one of claims 5 to 10, wherein each node is configurable to have a master/client or peer-to-peer relationship with another node.
12. 12. A network according to any one of claims 5 to 11, wherein the nodes are configured to communication with each other using a stateless requestresponse process.
13. 13. A network according to claim 12, wherein the nodes are configured such that a transaction between two nodes can be effected by one requestresponse pair in which the transaction reply is carried in the response or by first and second request- response pair, initiated by respective nodes, in which the transaction reply is carried in the request of the second request-response pair.
14. 14. A network according to any one of claims 5 to 13, wherein nodes are configured to respond to a message with a response message including user - 23 - interface defining data and one node provides an externally accessible interface and is responsive to a request at said interface to: transmit messages to other nodes; receiving response messages, including user interface defining data, from said other nodes; aggregate said user interface defining data; and transmit the aggregated user interface defining data to the source of the request received at said interface.
15. 15. A network according to claim 14, wherein the user interface defining data comprises mark up code.