Old WSS Server Documentation

Method of Operation

Initialization

• The WSS server is launched on some port in USARsim.
• Robots connect to it and send a REGISTER command.

Comms

• Robot A sends a LISTEN command, telling the server that it is listening on a TCP port.
• Robot B sends an OPEN command, telling the server that it wants to connect to a port on Robot A from some port on Robot B.
• The WSS server opens TCP sockets to both Robot A and Robot B, on their respective ports.
• On the newly opened sockets, Robot A and Robot B can transmit and receive SEND commands.
• When done, one of the robots closes the TCP connection, at which point the other connection is also closed by the WSS server.

Notes:

• If a connection is lost in simulation, the WSS server will immediately close both TCP connections to the robots.
• I have no idea why CLOSE commands are useful. Maybe the opposite of REGISTER?
• It's rumored that putting ';' in a SEND command, even though it supports binary strings, can screw up parsing. Thus, if we see unexplained comm errors, we should consider preprocessing our messages to remove ';'.

Machinetta Implementation

• Robots start up and register with WSS server immediately, using information from their cfg/blf file.
• When a robot sends a message to another robot the following occurs:
  • If a connection exists, the message is serialized and transmitted over the existing link.
  • Otherwise, a connection attempted to the destination robot. The message is scheduled to be resent later.
  • If the connection succeeds, it is cached, in case a future message has the same destination.
  • If a connection is lost, it is simply deleted from the cache.

Details

• A server socket is setup that listens constantly for incoming connections.
• When a connection is made, an AgentLink is created for each side.
• AgentLinks immediately send each other a message consisting of the following:
  • SEND msglen {[Stream Setup][ProxyID]};
  • SEND 4 DONE;
• After this, it is assumed that all subsequent messages are objects.
• Objects are serialized and fragmented into the following:
  • SEND msglen {[OBJ_A Part1]};
  • SEND msglen {[OBJ_A Part2][OBJ_B Part1]};
  • SEND msglen {[OBJ_B Part2]};
  • SEND 4 DONE;
• Received SEND commands are buffered until a DONE is received, then deserialized. Multiple objects could be sent in a single message, but functionality to transmit object arrays does not yet exist.

Notes:

• What do we do when messages fail to get passed? Generate new beliefs?

-- PrasannaVelagapudi - 06 Jun 2007