Iclient/Iserver: Distributed Objects using [incr Tcl]

package require Iserver
class Counter {
    inherit ::iserver::Distributed
    method bump {} {return [incr count]}
    method value {} {return $count}
    private variable count 0
}
Counter foo
::iserver::listen 8066

The server begins by initializing the Iserver package , thereby creating commands and base classes that the server needs. It then defines an [incr Tcl] class Counter with two methods bump and value . By inheriting from the Distributed class, the Counter class is able to share its objects with clients. The server creates a Counter object called foo , and then opens a socket on port 8066 and waits for clients to connect and start using foo .

Now suppose there are two clients that would like to use the server's foo object. Each client needs to load the Iclient package, and then connect to the server. It does so by creating a Server object, and telling it to connect to the server listening at port 8066 on the machine sercial.micro.lucent.com:

package require Iclient
set serv [::iclient::Server #auto sercial.micro.lucent.com 8066]
$serv resolve class Counter
$serv resolve object foo
foo bump

Now that the client is connected to the object server, it can attach itself to the Counter foo . To do this, the client resolves the names of both the class, Counter , and the object, foo . In other words, the client has gone to the server and created its own, local copy of Counter and foo , which it can use to access the actual, server entities of the same names. All the client needs to do is call the bump method on its object, and Iclient will take care of running bump on the server object foo .

...
button .bump -text "Bump" -command {
    foo lock {
        .count configure -text [foo bump]
    }
}
pack .bump -side left -padx 6 -pady 10
label .count -text [foo value]
pack .count -side left -padx 6 -pady 10

foo watch lock {
    .count configure -text [foo value]
}

This example uses two object services of Iclient/Iserver: lock and watch. When pressed, the button .bump requests a lock on foo . It then increments its value by calling the bump method.
 

Interprocess communication presents a host of concurrency problems that occur when two clients try to manipulate the same resource at the same time. In Iclient/Iserver, most method calls will be atomic, unless they access the event loop. To be certain of exclusive access to a server object, a client should request a lock whenever modifying a server object.

if {[foo value] < $maxBid} {
      foo bump
}

What makes this example different is that the clients want to check the state of an object, make a decision based on that state, and then call another method on the object to change it. Without locks, there is a classic race condition where it is possible for a client to make the wrong decision about whether to bid.

foo lock {
      if {[foo value] < $maxBid} {
            foo bump
      }
}

This is guaranteed because once the first client acquires the lock on foo , it is the only client allowed to access foo until the lock is removed. If another client tries to access foo while the first holds the lock, it will have to wait until the lock is released.

foo lock {
    .count configure -text [foo bump]
}  -timeout 20000 -suspend  {
    .count configure -text "Acquiring lock"
}  -continue  {
    .count configure -text "Lock acquired"
}

One more detail remains to be explained: when one client bumps the value of foo , the other clients need to know that foo has changed in order to update their displays. Clients can watch objects, and register a callback that will run when a particular event occurs to the object. This is similar to a variable trace or to a binding on a Tk widget. Keeping track of an object being locked is rather straightforward. The clients can watch for foo to be locked; when that occurs, they know that foo has changed, and they can call the value method to learn the new value of the Counter . Clients can watch any object, looking for well-defined or custom-defined events to occur. Well-known events include lock , destroy , and resolve . Distributed objects can report custom events by using the report method, as in the following:

class Counter {
    inherit ::iserver::Distributed
    method bump {} {
        report "bump"
        return [incr count]
    }
...
}

The last services that Iclient/Iserver provide are the ability to restrict use of a server object to a subset of connected clients. An object server gives each of its clients an unique id, and can use this id with the Distributed class's restrict method. Here a server restricts use of the object foo to a single client with client id client1 :

foo restrict {client1}

In any client/server architecture, an API mediates between clients and server services. In the remote procedure call (RPC) approach, the server program publishes a set of commands that clients use to communicate with the server. An RPC approach works well for procedural applications, such as vanilla Tcl scripts, where command provide the only interface for performing operations.

It is possible for a client to be connected simultaneously with multiple object servers. Iclient provides a class Server to help client scripts to keep track of a given object server connection. When a client wants to connect to a new object server, it creates a new instance of this Server class and feeds it information about the hostname and port number of the object server. The methods of the Server class provide a secondary API that clients use to access an object server, to create client stubs, create new server objects, destroy server objects, and inquire about objects available on the server.

The central task for Iclient/Iserver is to allow clients to access server objects in a manner consistent with accessing ordinary [incr Tcl] objects in a stand-alone application. To do this, a server object must appear as if it lived locally, on the client. It must also have the same methods as the server object, and the client must be able to call those methods as with ordinary [incr Tcl] objects.

To accomplish this, Iclient/Iserver literally creates a client-side object to act as a stub for the server object the client would like to use. These stubs are [incr Tcl] objects; therefore, the client requires a class declaration to produce the stub. The Server class that servers as an API to access an object server provides a method resolve that resolves the binding between the client stub and the server object.

Iclient/Iserver provides both implicit and explicit mechanisms for resolving references to server objects. In the implicit model, the client code does nothing to resolve references to server objects. The client merely connects to an object server, and starts using well-known objects. To return to the Counter example, suppose a client runs the following code:

package require Iclient
set serv [iclient::Server #auto sercial.micro.lucent.com 8066]
foo bump

The client has connected to an object server but has done nothing to link the server object foo to the client. The client proceeds anyway, calling the bump method of foo . The Tcl parser looks for a command named foo but cannot find one defined. Ordinarily, the parser would raise an error saying that the command foo does not exist. But Iclient has changed the way Tcl handles unknown commands by introducing its own handler into the built-in unknown command.

$server ask identify foo

The ask command is a primitive to Iclient and Iserver that allows a process to send a Tcl command to another process and wait for the result. In this case, the client sends the script "identify foo " to the server, who will evaluate the identify command. This command looks to see if foo is either the name of a distributed class or a distributed object on the server. The server determines that foo is an object, and sends a reply to be evaluated in the client:

respond 1 0 "object Counter"

The respond command is used to tell the client that the server has a formulated a response to one of its ask requests. It reads the return code and the return value from the server, and learns that foo is an object of class Counter . The client knows that foo is a Counter object, and tries to create it on the client side:

Counter foo

Unfortunately, the client has also never seen the command Counter before. The unknown command runs again, this time looking for Counter , and asks the server if it knows of a name Counter:

$serv ask identify Counter

This time the server replies that Counter is a class. The client asks the server to supply a class stub for the Counter class:

$serv resolve class Counter
Counter foo

The server must now generate a stub for the class Counter , and pass the stub for the client to use. This involves creating a new class declaration that has only the public methods of Counter . These stub methods are not implemented as they are in the client class declaration; instead, each is a wrapper around an interface that runs the same method on the server object. The stub class declaration created for the Counter class might look like this:

class Counter {
    method bump {args} {
        return [eval $server ask object invoke [namespace tail $this] bump $args]
    }

    method value {args} {
        return [eval $server ask object invoke [namespace tail $this] value $args]
    }
    ...
}

Now the client has a stub for the Counter class. It can now try to resolve a reference to foo .

$serv resolve object foo

The client asks the server to help it resolve a reference to foo. This causes the client to create a client stub called foo using the class declaration previously generated by the server. With the stub in place, the client can now invoke methods on the stub; when it does so, the stub will ask the server to invoke its own object named foo and will use the response from the server as its return value.

This rather detailed chain of events is illustrated in the figure below. What is important to realize is that all this detail was handled by the Iclient package; the client script set this into motion by the innocent looking call of foo bump . The entire process of resolving is transparent to the programmer, who needed only to create an object on the server, and use that object on the client.

To solve these problems, Iclient also offers an explicit interface for generating client stubs. A client can request a stub from a Server object, by calling that object's resolve method.

set serv [Server #auto sercial 8066]
$serv resolve class Counter
$serv resolve object count mycount

[ Top ]

Iclient/Iserver primitives

Iclient/Iserver relies upon a handful of primitives to organize message passing between clients and servers. These primitives include ask , tell , and respond . Whenever a client communicates with a server, or a server communicates with a client, one or several of these primitives are used.

respond 1 0 "object Counter"

Iclient/Iserver makes heavy use of core Tcl sockets, file-events, safe interpreters, and the unknown handler to implement distributed objects. Other sources discuss how to connect two processes with Tcl sockets so that each can send and evaluate Tcl commands on the other. Iclient/Iserver follows this approach, and extends it for use with objects [10].

The server evaluates commands sent from its clients in a safe interpreter, to prevent malicious clients from evaluating destructive commands in the main interpreter. Imagine if a client ran a troublesome command:

$server ask exec rm -rf .

[ Top ]

Application: Hearts

In this section, we will build a game of Hearts that allows four players across a network to meet and play the card game Hearts. Hearts is a card game usually played by four or more players around a table. Our game will allow players to meet up at a hearts server running in some well-known location, choose a game to join, and then play a game of Hearts. Each player will need to have his own interface with which to play the game.

A client/server approach is natural for this application. There are multiple players, each of whom have their own cards that they want to hide from the others. Each player will be running their own client to play the game, but will need to coordinate their play with the other clients. A Hearts server will manage the deck of cards, synchronize the actions of the clients, and control the flow of the game.

One possible approach to implementing this application is to build a stand-alone version first, that runs on a single machine and lets players take turns playing. There are a lot of details to organize for each game of Hearts-- players playing cards, checking their score, organizing their hands--and the engine needs to keep track of what cards have been played, decide whether a player has selected a valid card, etc. On top of this, there are many concurrent games of Hearts being managed by the same server. This problem is neatly solved using an object approach, to help encapsulate each of the Hearts games being played, and to establish a convenient interface between the client and server parts.

The Gamemanager class manages Game objects, helping clients to create, join, and quit new games. It also allows clients to register as players, with names and email addresses.

The server initializes itself by defining all the classes it will use during its lifetime, and by creating a well-known Gamemanager object, gm.

package require Iserver
class Gamemanager {
    method games {}
    method players {}
    method newplayer {option args}
    method newgame {option args}
}
class Game {
    method players {}
    method join {}
    method quit {}
    method cards {}
}
...
Gamemanager gm
iserver::listen 8181

The following block shows how a client might fill a listbox .games with description of the Game objects that the Gamemanager gm knows about. The binding places the selected Game 's players in the listbox .players . The button .join asks to join a Game.

proc show_games {} {
    global games
    .games delete 0 end
    set games [gm games]
    foreach game $games {
        set desc [$game description]
        .games insert end $desc
    }
}
proc show_players {game} {
    .players delete 0 end
    set players [$game players]
    eval .players insert 0 $players
}
bind .games <ButtonPress-1> {
    set idx [.games curselection]
    set game [lindex $games $idx]
    show_players $game
}
button .join -text "Join" -command {
    $game lock {$game join}
}

$game watch lock {
    show_players $game
    show_games
}

gm watch lock {
    .games delete 0 end
    set games [gm games]
    foreach game $games {
        .games insert end [$game description]
    }
}

card_draw [$game cards]

When the player is ready to play a card, they drag the card to the center of the table. The game of Hearts is played by following an order of play. One player leads by playing a card on the table, then play moves around the table in a circle. If our client tries to play a card, the server must first decide if it is that player's turn.

The Turn object keeps track of the order of play for a given trick, and prevents players from playing out of turn. Players invoke the play method of the Turn object in order to play a card.

To do this, the client requests a lock on the Turn object. The Turn class exists primarily to regulate whose turn it is, and to allow only the appropriate player to play a card. To accomplish this, the Turn object establishes a set of locks on itself for each of the players playing the game. These lock requests enter a queue, and are entered in turn order. If a client tries to access the turn object prematurely, then that client must wait for the players ahead in the play order to play their cards; as soon as they are finished, then our client acquires the lock and plays a card.

Client Code

$turn lock {
    $turn play DK
}

Server Code

class Turn {
    inherit ::iserver::Distributed
    private variable order;
    method newturn {}
    method discard {}
    private method accept {card}
         method play {card} {
            set player [::iserver::current]
            set turn [lindex $order]
            if {$player == $turn} {
                accept $card
                report $discard
                return
            } else {
        error "Not your turn"
        }
    }
}

The Turn object controls the order of play. With every trick, the Turn object calculates the order of play based on the rules of Hearts. When a player attempts to play a card , the Turn object asks Iserver who this client is, and checks to see if it is the client's turn. If it is, the Turn object accept s the card , and reports a discard event to let the other clients know to redraw their canvases. If the player should not be able to play yet, the Turn object does not let the player play.

All of the clients are going to be interested in the cards that the other players have played, in order to draw them in the center of the canvas. To watch for players playing cards, each client watches the Turn object. When another client accesses the Turn object to play a card, the server notifies each of the clients, who then learn which cards were played and draw them:

turn watch discard {
    set cardsPlayed [$turn discard]
    discard_draw $cardsPlayed
}

Notice that the script a client runs in response to watch event can do anything; it does not need to limit itself to accessing just the object being monitored. The client is watching the turn object to see when a card is played; once it is notified, it calls the discard method of the Turn object to learn which cards were played, and then draws them using the discard_draw command.

Server Code

class Chat {
    method listen {} {
        set client [::iserver::client]
        ::iserver::list_add listeners $client
    }
    method talk {mesg} {
        set speaker [::iserver::client]
        foreach client $listeners {
            ::iserver::tell $client rpc chat_mesg $speaker $mesg"
        }
    }
    variable listeners
}

Client Code

$serv rpc chat_mesg {speaker mesg} {
    .chat.text insert end $speaker $speaker "\t$mesg" $speaker
    .chat.text see end
}

[ Top ]

Conclusions

Using class methods as a natural interface between clients and server, distributed server objects allow efficient encapsulation of data and operations.

Iclient/Iserver fills a niche between simple Tcl-based remote procedure call systems like Tcl-DP and comprehensive object brokers that follow the CORBA standard. It provides an easy way to construct client/server applications while eliminating the need to write a separate set of remote procedure calls. Distributed server objects, visible and accessible by all connected clients, provide a natural interface for sharing information. The locking and object watching services provide synchronization and event notification to avoid concurrency headaches, including the need to poll continuously to see if the server has changed.

Using Iclient/Iserver protocols, starting to create client/server applications is easy, requiring trivial changes to the server objects that will be distributed and a few lines of code on the server and client ends to establish a connection. After that, the client resolves the objects it wishes to use, and invokes server object methods through its own client stubs.

While the approach is convenient, it can generate a lot of server traffic, since every remote method call requires a network transaction. Future work will examine how best to allow clients to cache additional information in their client to avoid talking to the server to perform read-only operations. This will obviously involve increased complexity in designing classes, and may raise a new set of concurrency issues, but it stands to improve performance and scalability where many clients access a single server.

Future work will also improve security in the system, to allow servers to authenticate connecting clients. Present security is achieved by evaluating socket traffic through a safe interpreter, which restricts the entry-points to the server to the methods of its distributed objects. If the server could authenticate its clients, then it could provide distributed objects that performed more trusted operations with greater security. Finer control over the methods that a given server object publishes to a specific client could also help to create more flexible server classes.

With version 3.0, [incr Tcl] has become a pure extension to Tcl/Tk, allowing vanilla interpreters to use classes and objects by loading [incr Tcl] as a package. With this support, these developers who enjoy the flexibility of scripting and the structure of an object system can use [incr Tcl] without having to build their own custom interpreters. By loading Iclient/Iserver, these same developers can use their existing classes as interfaces and construct client/server applications faster and more easily than ever before.

[ Top ]

Acknowledgments

Thanks to Michael McLennan and George Howlett for many useful discussions about client/server architectures and distributed objects, and for their help with this paper. Thanks also to Michael McLennan for his help in designing the interface for Iclient/Iserver software. Finally, thanks to Robin Valenza for losing sleep to edit this paper.[ Top ]

References

1. Jacob Levy, "A Tk Netscape Plugin," Proceedings of the Fourth Annual Tcl/Tk Workshop `96 , Monterey, California, July 10-13, 1996.
2. Michael J. McLennan, "[incr Tcl]: Object-Oriented Programming in Tcl," Proceedings of the Tcl/Tk Workshop, University of California at Berkeley, June 10-11, 1993.
3. Michael J. McLennan, "The New [incr Tcl]: Objects, Mega-Widgets, Namespaces and More," Proceedings of the Third Annual Tcl/Tk Workshop `95 , Toronto, Ontario, Canada, July 6-8, 1995.
4. Robert Orfali, Dan Harkey, and Jeri Edwards. The Essential Distributed Objects Survival Guide. John Wiley and Sons, 1986. ISBN 0-471-12993-3.
5. https://www.omg.org
6. B. C. Smith, L. A. Rowe, and S. Yen, "Tcl Distributed Programming," Proceedings of the Tcl/Tk Workshop , University of California at Berkeley, Jule 10-11, 1993.
7. Peter T. Liu, Brian Smith and Lawrence Rowe, "Tcl-DP Name Server," Proceedings of the Third Annual Tcl/Tk Workshop `95 , Toronto, Ontario, Canada, July 6-8, 1995.
8. M. Roseman and S. Greenberg, "Building Real Time Groupware with GroupKit, a Groupware Toolkit," ACM TOCHI , March 1996.
9. Mark Roseman, "Managing Complexity in TeamRooms, a Tcl-Based Internet Groupware Application," Proceedings of the Fourth Annual Tcl/Tk Workshop `96 , Monterey, California, July 10-13, 1996.
10. Mark Harrison, Michael McLennan. Effective Tcl/Tk Programming. Addison-Wesley, 1998. ISBN 0-201-63474-0.

[ Introduction | Counter: A Simple Example | Architecture | Distributed Object Model | Iclient/Iserver primitives | Application: Hearts | Conclusions | Acknowledgments | References ]