Using %rebserver.r

Source code originally from REBOL Technologies
Usage document written by Brian Tiffin, Library Team apprentice
21-Apr-2007

Contents:

1. Introduction to %rebserver.r

This early example of using REBOL for network client-server applications is definitely worth a close examination.

Anyone that has programmed network applications before should be amazed at the simplicity.

1.1 At a glance Quick Start

1.1.1 Start a rebserver in one window

$ rebol rebserver.r

1.1.2 Start a console session in another window and send a command

$ rebol
>> write tcp://localhost:4321 {print "Wow!, so easy"}

1.2 Further reading

For some background information on REBOL client server
scripting, see Cal Dixon's excellent tutorial at
http://www.rebol.net/cookbook/recipes/0028.html

Details on REBOL ports can be found in the REBOL/Core manual
at http://rebol.com/docs/core23/rebolcore-14.html

2. Using %rebserver.r

The %rebserver.r script is the server side of the equation. Just DO it and your REBOL process will dutifully wait for and execute the commands transmitted to it.

But what about the client side? This short usage document will show you what can be done.

The samples here where tested with REBOL/View 2.7.6.4.2
and REBOL/Core 2.7.6.4.2.  The examples use GNU/Linux.
REBOL is cross platform, but getting REBOL running is
Operating System specific.

3. Detailed first runs

3.1 Starting the server

In a console session window, run the server process with

$ rebol -s rebserver.r

This starts up REBOL with security set to ALLOW, so clients will have full access control.

Read the note in the %rebserver.r source. This application should NOT be used on an insecure internet connected machine. It exposes a port that will run ANY REBOL code sent to it. You want to make sure that it is only your code that executes and not a stranger's code.

3.2 Running a client

Start up a new console session in a different window.

If you are not using an X-Windows Graphical Desktop
just Ctrl-Alt-F2 to a new login screen and log in again
from this second GNU/Linux virtual console

In the second window start a REBOL console session with

$ rebol

REBOL/View may start up the graphical Viewtop press the "computer screen" icon labelled Console to continue to the REBOL console prompt.

Once the REBOL console is running try this

>> write tcp://localhost:4321 {print "Hello from REBOL"}

Look at or switch to the first session, with the server running and you should see

Hello from REBOL

dutifully displayed on the screen. How easy was that?

Try

>> write tcp://localhost:4321 {probe system/script}

and the server window will display it's system/script object.

4. If it didn't work

If you didn't see any message displayed on the session that is running %rebolserver.r then we get to start problem solving.

1. If %rebserver.r failed to run, there may be another process on your computer that has already opened port 4321. You may have to change the default port value.
2. Check the write oneliner, make sure it was typed correctly.
3. Does your server machine run a firewall? If so, you might get an error mentioning a problem connecting to the port. Configure your firewall to allow access to port 4321 and try the write again.
4. After that, ask for advice on the REBOL3 Altme World, the REBOL mailing list, or www.reboltalk.com. The REBOL community is full of friendly, helpful and very smart people.

5. Listener ports

If you read through the %rebserver.r file, you'll see that it opens tcp://:4321. This is a REBOL listener port specification.

The client side in our example uses tcp://localhost:4321. This network port specification is a little different and tells REBOL to handle the network operation in a slightly different way.

5.1 Trying to open another listener

If you tried to

>> write tcp://:4321 {print "Hello"}

while %rebserver.r is running on the same machine, REBOL may report

** Access Error: Error opening socket listen port
** Near: write tcp://:4321 {print "Hello"}

REBOL knows from the port specification that this is a socket listen port and that our other session (the one running %rebserver.r) is already listening. Only one listener allowed on each port. It wouldn't have worked even if the server was not running, but for a different reason, as described in the next section.

5.2 No server running, trying to write to a listen port specification

If %rebserver.r was not yet running and you tried

>> write tcp://:4321 {print "Hello"}

REBOL would report this error

** Script Error: Cannot use insert on this type port
** Near: write tcp://:4321 {print "Hello"}

tcp://:4321 is a listen port specification, and write is not used for listening.

5.3 No server running, trying to transmit a command

If %rebserver.r is not running and you try

>> write tcp://localhost:4321 "print 1"

You would see

** Access Error: Cannot connect to localhost
** Near: write tcp://localhost:4321 "print 1"

and that is because no one is listening.

5.4 Note the difference

tcp://:4321 and tcp://localhost:4321 are two port specifications that look similar, but REBOL, being the smart little piece of technology that it is, knows that the first specification is for listening, and the second form is for connecting.

6. Useful things

Let's see what else this simple application can do. The possibilities are nearly endless as this server can execute any REBOL code that is sent to it.

As mentioned in the %rebserver.r source code, this tiny server can assist in co-ordinating computers working on a common task. REBOL Technologies uses this script to synchronize cross platform builds.

Perhaps your empire is expanding and you need to keep track of completion records for your abundant employees. They could have a little script that they execute as a project passes through phases,

REBOL [
  Title: "Inform management"
  File: %tell.r
]

tell: func [
  "Report status to the boss"
  msg "The note to send"
  /local cmd
][
  cmd: rejoin [
      {write/append %bigproject.log reform [now "}
       read dns:// {" "} msg {" newline]}
  ]
  write/lines tcp://localhost:4321 cmd
  comment {
    the write line above would use the hostname of the
    rebserver machine ... it is localhost here for
    demonstration
  }
]

tell any [
    system/script/args  
    ask "What do you want to tell the team? "
]

which a developer could then execute, when finished a task, with a simple

>> do %tell.r

or

>> do/args %tell.r {Finished the revault module for the new
       mpeg/4 video codec}
>> tell "Starting code for the VID control widgets"

and you, the boss, would have a nice time stamped log file of developer status notes.

6.1 Default security

If you are running %rebserver.r with just

$ rebol rebserver.r

without a security override of -s, this tell function will not work. The server will try and write to the %bigproject.log and will fail. REBOL will not let scripts write to disk under normal security settings. A very smart and safe default.

7. Final notes

Using REBOL, you may just find yourself running a large technical empire...so be careful.

Page for page, REBOL programming outpaces most other software development environments and your programmers may produce more than you expect, faster than you expect.