danbikel.switchboard
Interface Client

All Superinterfaces:

Remote, SwitchboardUser

All Known Subinterfaces:

ParserRemote

All Known Implementing Classes:

AbstractClient, EMParser, Parser

public interface Client
extends SwitchboardUser

A semantic marker for SwitchboardUser implementors that are clients; also, specifies client-specific methods for the switchboard to use. Clients request and are assigned Server objects by the switchboard. Clients may also use the object-server facilities of the switchboard, requesting objects for processing, processing those objects and then sending the processed objects back to the switchboard for output (via the Switchboard's nextObject and putObject methods).

Implementors should ensure that they get SwitchboardRemote.clientNextObjectInterval from the settings of the switchboard, for use when processing objects. This is accomplished in AbstractClient by the AbstractClient.setNextObjectInterval() method.

A note on fault tolerance: In order to ensure the fault-tolerance of clients, implementors should ensure that they use socket factories that set the SO_TIMEOUT values of their TCP/IP sockets to some integer greater than 0, by providing custom socket factories that provide at least the functionality of TimeoutSocketFactory. Subclasses that use sockets other than TCP/IP sockets should have similar non-infinite timeouts.

See Also:

Server, SwitchboardRemote, AbstractClient

Method Summary

void	serverDown(int serverId) Tells a client that its server has died.

Methods inherited from interface danbikel.switchboard.SwitchboardUser

alive, die, host, id

Method Detail

serverDown

void serverDown(int serverId)
                throws RemoteException

Tells a client that its server has died. If the specified server ID is the same as that of the current server for the client, the client may respond either by eventually requesting a new server, or by committing suicide, by calling their implementation of SwitchboardUser.die(boolean).

Important synchronization note: This method should be non-blocking. That is, it shouldn't wait for some switchboard resource (such as a new server) or information to become available before returning. If this condition is not met, then deadlock could occur.

Throws:

RemoteException