Computer Science Canada [Tutorial] REBOL Client Server |
| Author: | btiffin [ Sat Apr 12, 2008 9:40 pm ] | ||||||||
| Post subject: | [Tutorial] REBOL Client Server | ||||||||
REBOL Client/Server By Brian Tiffin April 2008 By the way ... the designer pronounces REBOL as rebel. Network Messaging REBOL, the Relative Expression Based Object Language is built for networking. Combined with it's messaging features, Client/Server programming is a breeze. port! as series! A network port! datatype follows the ubiquitous everything is a series paradigm of REBOL. This means accessing ports uses the many and varied series! functions. This will be explained further during this tutorial. rebserver.r The rest of this tutorial will use a well known REBOL script, rebserver.r as an example and reference. The link shows the entire script with full header, this is the just the code.
Listen ports Servers open listen ports, then wait for connection requests. After a connection is established, two-way communications can occur. In the above script, server-port is set to an open listener using tcp/ip port 4321 and, of course, on the machine that is running rebserver.r. This port is opened in line mode, meaning data will be returned by line, not by packet. The script then begins an endless loop, the forever. Inside the loop, connection-port requests the first of the server-port. first is a series! operation returning the first element, and REBOL internals deal with the details of what that means for a listener port!. until evaluates a block! until it is true, which in this case is an error occuring in processing requests. The wait connection-port will wait until a connection request is received before continuing through the script. Then, in one line of REBOL code, will attempt to evaluate any data received, testing for errors as it does so. The first connection-port is the code that returns any data from the client. REBOL messaging facilities makes this pretty easy. There is no SOAP or ORB datatyping to worry about. Any REBOL data can be sent through the network connection and will arrive intact. In this case, with a line oriented connection, string! is a good choice but other types are easily possible, just not really appropriate to this example. The do evaluates the returned value as REBOL code. The try block! traps any errors that may occur and error? will test to see if the try returned an error or a valid value. The result of this test is used by the until loop. True values, meaning an error occured, will close the current connection and then, in the forever loop, wait for another connection. And that is it. A server that will accept remote client requests and evaluate code. Note: This is NOT something you run on an unsecured, internet connected host. It is intended for tasks such as sending build commands to a central server inside a firewall. A client for our server Clients are just as easy to write as servers.
That will send print "Wow! how easy was that" to the server, which will evaluate the print and display Wow! how easy was that on its console. We could have opened a port!, but in this case we just write a string of REBOL code to the server port. REBOL takes care of all the details. localhost Every computer in a tcp/ip network knows of itself as localhost. It is a simple convention. The nodes may have other names but all tcp/ip enabled machines can reference themselves as localhost. This could have just as easily be;
or
These client examples assume you are running one REBOL instance for the server and another instance, on the same machine, for the client, to simplify the demonstration. Further reading Please see, Usage documentation for rebserver.r for details on using rebserver.r. A nice example of another client/server application can be seen at Client Server Cookbook Recipe. An example of multiple connections can be seen at Creating a Server Port in the REBOL Cookbook. As always, for more information, please visit rebol.com. REBOL was built for this mode of computing and some very powerful active internet applications are possible in very few lines of source. By being small, applications are easy to write, debug and maintain. Cheers |
|||||||||