Solid Fluid System Solutions  
Home Software About Hardware Firmware

Document Icon VConsole (Library)
Document Icon Crypto
Document Icon Archive
Document Icon Container
Document Icon Pipe
Document Icon Compress
Document Icon Math
Document Icon Vector
Document Icon DateTime
Document Icon List/Array
Document Icon HashIntegerFloat
Document Icon Database
Document Icon Thread
Document Icon String
Document Icon Machine
Document Icon Regex
Document Icon SGMLParse
Document Icon HTTPHeader
Current Document Icon Comm
Document Icon Collab
Document Icon HierAgent
Document Icon Resource
Document Icon Colour
Document Icon Image

Comm

The comm group is a multithreaded communications suite. It provides three main ways to communicate;

  • VTunnel
  • VPipe
  • VSocket

VTunnel, uses shared memory to communicate within a thread, or between threads/processes on a single machine. It's main advantage is that it is able to implement a broadcast transmission without having to replicate the message for each endpoint. It's disadvantage is that the shared memory block is not queued by necessity, and therefore it is fairly inefficient by comparison with a duplex communication medium like pipe and socket. Any tunnel endpoint must wait for all of the others to complete before sending a message. Queued duplex communication eliminates this problem.

VPipe, encapsulates a standard windows pipe. A pipe can connect any thread on any machine within a windows network. It cannot expand beyond the bound of a windows network. A pipe can communicate across the internet, but only if the windows network also bounds the part of the internet through which the pipe needs to communicate. The pipe connection is subject to windows security.

VSocket, is a standard TCP/IP socket. It connects within threads, or between threads/processes on the same or different computers. The only requirement is that the threads that can be seen by each other through TCP/IP. There is no implicit security with TCP/IP, with the exception of a firewall. TCP/IP would normally be secured by the applications on the client and server. This is an important security model because it allows incompatible computer architectures to communicate.

These three communication schemes all derive from the same base class, and therefore there is little overhead translating messages between them. The Comm group also defines a special message class which is used to send messages between the communicating objects. The message object typically contains a message code and an object pointer. Serialisation is used to transfer objects between the VComm end points. The message object is also used for the communication of system messages, which are transparent to the user.

Each of the three ways of communicating typically has a listener object used by the server and a plain object, used by the client. The client initiates a session by opening a connection with the server listener. Once the server has allowed the connection, the server spawns it's own plain object which does the actual communication with the client. For the sake of convenience all communication data from multiple server comm objects is routed through the listener server object. Although it is transparent to the client, the server has the capacity to assign link ids to each of many connections. This scheme ensures that it is possible for the server to match client requests to server responses.

System messages are used to implement initial connection and security. Such system messages are not generally visible to client or server users of the VComm scheme. VComm automatically implements an RSA public key sharing scheme which can be used to secure the data link. Connection is implemented securely by encryption, and protocol failure leads to automatic IP rejection. The collaboration objects in the Collab group work with VComm to implement authentication, but a server socket will not allow anything other than connection and a single authentication to take place until it is notified from within the server that authentication has completed. Once authenticated any message may either be secure and encrypted, or insecure and unencrypted, this decision is made by the sender, either client or server.

Copyright © Solid Fluid 2007-2022
Last modified: SolFlu  Mon, 08 Jun 2009 18:02:39 GMT