As a natural extension of CS-Prolog II channel concept, the external communication conceptually consists of unidirectional message streams. In order to facilitate speed-up of external communication, asynchronous message passing is introduced as an option. Send operation in this case still remains blocking but the condition for continuing execution is the availability of sufficient buffer space instead of the commencement of the matching receive operation.
For the Prolog programmer the communication environment appears as a homogenous address space (community). All partners will be accessed via channel messages. A separate mechanism is introduced for connecting channels to external partners. The most important entity for this task is the so-called port. Ports represent incoming message substreams. They are explicitly created and play the role of a sender for a CS-Prolog II channel specified at the time of port creation. The other end of the channel can be used in the same way as the receiving end of any internal channel. At port creation, a buffering parameter can be specified indicating the size of message buffer.
Another important notion in CS-Prolog II is the connection. A connection is the representation of an outgoing message stream. Its attributes include the local channel, the partner's name and the partner's port (if partner is not foreign) to where the stream is directed. Its size of the connection's message buffer can be set at creation. If the value of the buffering attribute is greater than zero then more than one message can be stored in the connection buffer, allowing several send operations to complete without blocking.
In a centralised subnetwork of CS-Prolog II applications managed by a (possibly foreign) manager program, the following types of partners can appear for a specific CS-Prolog II program:
Private partners; their addresses have to be available in advance for the program (hardwired in the program, obtained from a file, e.t.c.).
Net partners, which have signed up at the manager, and our program included them in its local picture of the network. The address of a net partner is obtained from the manager.
Latent partners, who are known by manager, but our
program didn't include them in its local network picture. The address of a latent partner
(and some other attributes too) can be asked from the manager.
In the current TCP/IP implementation of the CS-Prolog II low-level communication protocol, in order to be able to communicate with a net partner, a configuration process has to be performed as for private partners. In other words the program has to add explicitly this partner using special built-in predicate.
In future CS-Prolog II versions, if the underlying network layer provides the possibility of communicating with partners with known addresses without building a specific transmission path to them, the explicit configuration of net partners can be omitted.