Remote behaviors should be strictly client and server, with no intermediated

[GoogleCodeExporter]

In implementing remoteness, I've tried to allow for the possibility of a
server, delegating to an intermediate server, delegating to a client.  I
thought this approach would force me to focus on design, rather than lines
of code--even though that configuration probably would never be used.

That may have helped.  But now the concept of an intermediate is a
limitation because, as implemented, an intermediate server is
indistinguishable from the top-most server.

It should be better to treat "client" and "server" as aliases for actual
IPaddress:port network locations.  That way dotsTransaction objects can
have well-defined origins and destinations.

That will make it easier to implement "forward", or perhaps "report"
transactions, originating on the client end, to be enacted by the server. 
It will also eliminate the need for complex transaction "routing".

This should also make it easier to implement remote behavior for object
modes, if that becomes necessary.

Original issue reported on code.google.com by Benjamin.Heasly on 11 Dec 2009 at 5:48

[GoogleCodeExporter]

Indeed, there may be more than two machines involved.

I just met with Yale Cohen about his rig being developed for auditory stimuli.  
Certain 
device drivers will require than the auditory stimuli be generated form Matlab 
on a 
*Windows* machine.

Therefore, there could be a situation where a Snow Dots "server" machine is 
messaging with a Windows auditory stimulus client as well as an OS 
X/Psychtoolbox 
graphics client.

It will make sense to manage separate "client" sockets for messages two and 
from 
each machine.  So the concept of "client" should be more general.

Maybe dotsTheMessenger should provide to/from server methods for convenience, 
and to/from arbitrary socket methods, for whatever types of client are 
involved.  
These sockets should be managed and used by subclasses of 
dotsTheRemoteManager.

Original comment by Benjamin.Heasly on 17 Dec 2009 at 3:41

[GoogleCodeExporter]

Therefore, initialization of dotsTheMessenger will look different.  It probably 
will only 
care about serverMode, and only try to open a server socket.  Future sockets 
would be 
opened by manager objects.

Original comment by Benjamin.Heasly on 17 Dec 2009 at 5:33

[GoogleCodeExporter]

As of r43, subclasses of dotsAllRemoteObjectManagers are in charge of their own 
sockets.  dotsTheMessenger supplies socket identifiers and can open a default 
client 
and default server socket.

Original comment by Benjamin.Heasly on 29 Jan 2010 at 5:17

• Changed state: Fixed