![]()
|
11. Pyro ServicesThis chapter describes the various services that Pyro offers.Name ServerThe Name Server is such an important service that it is documented in a separate chapter.Event ServiceIn various situations it is needed that the servers and the clients are decoupled. In abstract terms this means that information producers do not know nor care about the parties that are interested in the information, and the information consumers do not know nor care about the source or sources of the information. All they know is that they produce or consume information on a certain subject.Here does the Event Service fit in nicely. It is a third party that controls the flow of information about certain subjects ("events"). A publisher uses the Event Service to publish a message on a specific subject. A subscriber uses the Event Service to subscribe itself to specific subjects, or to a pattern that matches certain subjects. As soon as new information on a subject is produced (an "event" occurs) all subscribers for this subject receive the information. Nobody knows (and cares) about anybody else. It is important to rembember that all events processed by the ES are transient, which means they are not stored. If there is no listener, all events disappear in the void. The store-and-forward programming model is part of a messaging service, which is not what the ES is meant to do. It is also important to know that all subscription data is transient. Once the ES is stopped, all subscriptions are lost. The clients that are subscribed are not notified of this! If no care is taken, they keep on waiting forever for events to occur, because the ES doesn't know about them anymore! Usually your subscribers will receive the events in the order they are published. However, this is not guaranteed. If you rely on the exact order of receiving events, you must add some logic to check this (possibly by examining the event's timestamps). The chance of events not arriving in the order they were published is very, very small in a high-performance LAN. Only on very high server load, high network traffic, or a high-latency (WAN?) connection it is likely to occur. Another thing to pay attention to is that the ES does not guarantee delivery of events. As mentioned above, the ES does not have a store-and-forward mechanism, but even if everything is up and running, the ES does not enhance Pyro's way of transporting messages. This means that it's still possible (perhaps due to a network error) that an event gets lost. For reliable, guaranteed, asynchronous message delivery you'll have to look somewhere else, sorry ;-) The Event Service is a multithreaded server (if threads are available). Publications are dispatched
to the subscribers in different threads, so they don't block eachother.
Note that you can still use the Event Server if your Python implementation doesn't
support threads.
Also notice that events may arrive at your listener in multithreaded fashion! Pyro itself
starts another thread in your listener to handle the new event, possibly while the previous
one is still being handled.
If you can't handle this, you have to use some form of thread locking in your client!
(see the Starting the Event ServiceThe Event Service is started using thees command from the bin directory (use es.bat on windows).
You can specify the following arguments:
A new utility is planned that is a more generic service manager. You'll be able to start, stop and configure the various services, including the Name Server. If you want to start the ES from within your own program, you can ofcourse start it by executing
the start script mentioned above. You could also use the Using the Event ServiceThe Event Service is a regular Pyro object. Its name is available inPyro.constants.EVENTSERVER_NAME .
The subjects are case insensitive. The patterns are matched case insensitive too.
Your clients (subscribers) need to call the Pyro daemon's handleRequests or
requestLoop (just like a server), because they receive Pyro calls, namely,
the Event Service callbacks when a relevant event happened!
A base implementation of a Note that the code below assumes you're talking directly to the Event Service, and that
you have it in a proxy object callled Publishing informationJust call thepublish method: ES.publish(subjects, message)
where subjects is a subject name or a sequence of one or more subject names (strings), and message is the actual message.
The message can be any Python object.
Subscribing to receive informationCreate a subscriber object, which must be a Pyro object (or use delegation). So your subscriber program should not only act as a Pyro client, but also as a Pyro server, to receive subscription events. The subscriber object should have aevent(self, event) method.
This method is called by the Event Service. event is
a Pyro.EventService.Event object, which has the following properties:
Your subscriber will receive all events that are published on the relevant subjects. If your subscriber is slow, a backlog will build up. You still get all events (with the original timestamp - so you could skip events that "have expired" to catch up). Currently there is no way around this. In a future version it might be possible to specify maximum backlog length.
The multithreading of the
To subscribe, call the
Pattern matching subjects: To subscribe on a pattern
that matches a range of subjects, call the Repeating it once more: the subjects are case insensitive. The patterns are matched case insensitive too. To unsubscribe, call the Using the skeleton Publisher and Subscriber codeFor the impatient, have a look at the "stockquote" example. This example is based on the skeleton code that comes with the Event Service. There are two classes that you can subclass from:
__init__ of both the Publisher and the Subscriber
takes an optional ident argument. Use this to specify the authentication passphrase that will
be used to connect to the Event Server (and also to connect to the Name Server).
ExampleTo see how you use the Event Service, have a look at the "stockquotes" and "countingcars" examples. Also have a look at the client skeleton code that comes with the Event Service.
|