- The network server provides shared network access to a given AtomSpace, via a telnet interface. There are other ways of accessing the AtomSpace over the network, documented below. However, the cogserver is faster, more efficient, more scalable and more stable (doesn't crash under load). This alone makes it quite useful for monitoring long-running compute jobs.
- The agents subsystem provides time-sliced processing "agents" called MindAgents. Unfortunately, this is subsystem is currently mis-designed and basically doesn't work. More generally, we need to solve the systems-management problem, described below. Currently, most users will find it easier to just create a new thread to run whatever task that needs to be performed.
OpenCog has a general, unsolved system management problem. We want to provide users with some way of starting and stopping various different subsystems, possibly on a distributed network of machines. We want to be able to easily find and load the correct dataset or datasets (the "memories" and "knowledge" of the system), to checkpoint the system, in case it crashes, and to save partial or final results. We want to manage the configuration of the system. We want to allow the user to make sure that the appropriate systems are not starved for CPU time, and to monitor overall system performance. Finally, large parts of this need to be automated and automatable, so that the attention allocation subsystem can control overall resource scheduling. The network server, the agent server and the config file are three parts that currently implement what we've got. However, they are inadequate, and need to be replaced by a more powerful, better solution for managing and controlling the system.
(So, for example: We've got no way at all for managing data, and we've got no control panel at all. I use the command line to copy files around, and use 'top' to examine running processes, and 'iotop' and 'iostate' to stare at disk utilization. I use 'tmux' and 'byobu' to avoid loosing running sessions, and I use 'ssh' for remote login. This is OK-ish, for now, but is not scalable to more than 2 or 3 different machines. If I had to manage ten machines with ssh, byobu, top, and copy around datasets by hand, start and stop cogservers by hand, load and save datasets by hand, it would be a nightmare. It will need to be automated, eventually.)
In this sense, its "OK" to continue to use the cogserver, but just be careful not to tie yourself to it: things will change when a more comprehensive system management infrastructure is developed.
Ideas: FWIW, there is a large variety of cloud management tools and systems, and perhaps OpenCog could pick and work with one of the smaller and simpler ones? We don't want to reinvent the wheel, here.
In practice, the CogServer is faster and more reliable than the Guile REPL server, demonstrated below. It also provides a network interface for Python; I was unable to find an off-the-shelf network server for python. Ideally, we should be able to replace the CogServer by some off-the-shelf, general-purpose, multi-featured network server. However, I was not able to find anything suitable after a brief search. A network server would need to provide:
- Authentication, using login credentials of some sort, or possibly via capabilities
- Encrypted messaging
- A capability framework so that different aspects of the OpenCog system could be accessed safely.
The REST API provides an alternative to the CogServer: it allows you to access atoms, without using the cogserver itself.
Example network alternatives to the cogserver
The netcat example is a cheap stunt, but it illustrates how simple it can be to create a network server. The guile example is practical, on a day-to-day basis for guile users. There are presumably similar network servers available for python and haskell.
Netcat REPL server
Netcat can be used to create a simple network server:
$ mkfifo /tmp/foo $ cat /tmp/foo | guile 2>&1 | nc -l 127.0.0.1 1234 > /tmp/foo
This creates a minimal network server listening on port 1234. You can connect to it from another shell:
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. scheme@(guile-user)> (use-modules (opencog)) scheme@(guile-user)> (Concept "foo") $1 = (ConceptNode "foo")
The biggest problem with this server is that it multiple users cannot connect to it. Its a bit too minimal to be practical. However it illustrates an important point: there is nothing special about the concept of a network server.
Guile REPL server
A usable network server can be created as follows. From the bash prompt:
$ guile Enter `,help' for help. scheme@(guile-user)> (use-modules (opencog)) scheme@(guile-user)> (use-modules (system repl server)) scheme@(guile-user)> (spawn-server)
This starts a guile REPL server on port 37146, the default. To pick a different port, see the guile documentation. You can now log into the this server: so, at another bash prompt:
$ rlwrap telnet localhost 37146 Enter `,help' for help. scheme@(guile-user)> (Concept "foo") $2 = (ConceptNode "foo")
Quit the connection by typing (quit) or ,q. Then verify that the atom is still there:
$ rlwrap telnet localhost 37146 Enter `,help' for help. scheme@(guile-user)> (cog-node 'ConceptNode "foo") $3 = (ConceptNode "foo") scheme@(guile-user)> (cog-node 'ConceptNode "bar") $4 = ()
The above is a two-line replacement for the cogserver.
It is important to load the opencog module in the main process, before starting the network server. This creates a common atomspace that all network connections share.
Python REPL server
There's probably a simple way to do this in python...