Text

1. A protocol to support sending and receiving text
2. Control of where text should be sent

1. Protocol

   The protocol defined here can be used either to communicate directly with another client, or for group communications it can operate via a server.

   SRDP

   Each text message is sent via SRDP to the recipient, allowing us to use UDP and avoid the overhead of opening TCP connections, while also ensuring a higher degree of reliability than UDP gives us.

   Packets used

   There are two command packets defined: the first to send text and the second to notify a server of interest.
   • TextSend Packet

     Sent By:

     Anyone

     Received By:

     Anyone

     When Sent:

     This is sent to communicate text from one client to another (possibly via a server)

     Interpretation:

     Text has been received from another user, display it appropriately, e.g. in a scrolling text box, or bubble. The client may need to send a GetX(NAMETYPE,ID) to the ID Server to find out the name of the sender.

     Fields:
         Command=TEXTSEND
         ID               (The ID of the sender)
         Text 
     

   • TextNotify Packet

     Sent By:

     Client

     Received By:

     Text Server

     When Sent:

     When a client wishes to "subscribe" or unsubscibe to text from a server, and every 30 seconds afterwards to keep alive.

     Interpretation:

     The server needs to add the ID, or reset the timeout for the ID, to a list of recipients of text passing through it. If the ID is invalid the ID should be removed from the list.

     Fields:
         Command=TEXTNOTIFY
         ID               (The ID of the sender, 0 to sign off) 
     

2. Where to send Text

   • Other Avatars

     Sending text to another user is done on a peer-to-peer basis. The sending client needs to know the destination IP address and port to send to, which is obtained via a GetX packet. A typical interaction looks like.

     ClientA	->	ID Server	GetX(ID-B,ADDRESSTYPE)
     ID Server	->	ClientA	SetX(ID-B,ADDRESSTYPE,12.34.56.78,9000)
     ClientA	->	ClientB	TextSend(ID-A,Hi there)
     ClientB	->	ID Server	GetX(ID-A,NAMETYPE)
     ID Server	->	ClientB	SetX(ID-A,NAMETYPE,Joe Smith)
     ClientB			Displays "Joe Smith: Hi there" in the text window

   • Sending Text

     To send text to a server, we need to know where to send it, this is accomplished with the Activate Node, and a new URL type, the syntax is still being discussed, but for example a Podium might have a node like:

        DEF Podium RegionSensor {
             bbox ~~~~~~     # define a volume around the podium for sensing
          }
     
         Connect {
             while Podium.isIn
             to [ "vrmltextto://server.com:1234"]      # send text to the server
        }
     

     A client may only have one sink for text it generates at a time, when a vrmltextto is activated it should push the current "vrmltextto" URL onto a stack, and send all new text typed to the new "textto". Ideally in the case of something activated by CLICK, then sending the text (typically hitting Return) should pop the previous "vrmltextto" off the stack. The effect of this, is that a client can be participating in a group communication by virtue of their location, then click on a Avatar to send them an aside, automatically returning to the previous communication. In the case of a "vrmltextto" activated by "isIn", then leaving the Activation node (i.e. exiting the space defined by its geometry) should cause the stack to be popped. An example of this, would be being in a room, conversing with neighbours, then approaching a table, which captures the attention of people around it, on leaving the table the user would be back in the room.

     When a client has NO vrmltexto's activated, then it will select the Avatar's closest to itself, and send the text to a number of them (maybe 5 to 10).

   • Receiving text from a Server

     Receiving text from a server is a little more complicated, to handle text with a server, we still need to know where to send text, but we also need to let the server know that we are interested. This is handled by a different URL with a typical node looking like.

        DEF MyTable RegionSensor {
             bbox ~~~~~~     # define a volume around the table for sensing
          }
     
         Connect {
             while MyTable.isIn
             to [ "vrmltextto://server.com:1234", "vrmltextfrom://server.com:1234"]      # send text to and receive from the server
        }
     

     There are three things to note in the above Node
     1. The Geometry of the Activate node is larger than the Geometry of the Table itself, so that an Avatar approaching the table activates it.
     2. The "vrmltextfrom" causes the client to tell the specified server that it is interested in seeing a copy of all input that goes to the server.
     3. A client may have a number of "vrmltextfrom" servers active at any time, for example in a chat room, it might be receiving text from the main speaker, and from those sitting around the same table
     4. There is no need to notify the "textfrom" for an Avatar, the other user communicates with you by taking an action.
     The client needs to periodically send a textfrom to the server, which will time it out after a certain period (say around 1 minute), this is to avoid lost sign-offs, or vanishing clients, being a big problem.

Test cases

A single speaker in a room by a "Podium", and the ability to ask questions or chat with neighbours.

Have a vrmltextto on the podium, activated by clicking on it (asking questions) or proximity( (the speaker), the server can set "floor-control" policies.

A number of speakers having a panel discussion behind a table.

Solved as for the podium, but with a different bounding volume.

A crowded room with too many people in it to talk to all of them

Solved by clients deciding how many neighbours to send text to.

Person to Person

The user clicks on the desired conversation partner.

A table, everyone near the table talks to each other,

Illustrated above, vrmltextto and vrmltextfrom inside the Activation node which surrounds the table.