... | ... | @@ -15,17 +15,31 @@ The figure shows the main objects of the communication between the server and cl |
|
|
- Positions of the axis
|
|
|
- Get the list of simulated servers
|
|
|
- Pause/restart the animation
|
|
|
|
|
|
#### Current protocol
|
|
|
|
|
|
The 3D model data are binary data and can be very big for finest LODs and common websocket messages cannot hold such data.
|
|
|
|
|
|
That is why using the streams was a solution and allowed to transfer big data with the chunks. However only using the stream for all requests/responses forced to implement a special "protocol".
|
|
|
here is how the communication works.
|
|
|
When a client opens a connection on the server, a stream is opened between the server and the client, meaning that there is as many streams as the number of clients. For each type of request, there is a handler that is why the data collected must be dispatched to the correct handler e.g. there is a handler for the positions request, another one for pause/restart requests, etc.
|
|
|
To implement the dispatch, the messages are organised as follows:
|
|
|
- start: the name the request hashed into a fixed length word with _START_.
|
|
|
- content, binary or ascii depending on the type of request.
|
|
|
- end: the name the request hashed into a fixed length word with _END_.
|
|
|
To implement the dispatch, the messages (or chunks) are sent in the following sequence:
|
|
|
- start message: the name the request hashed into a fixed length word with _START_.
|
|
|
- content messages: sequence of binary or ascii messages depending on the type of request.
|
|
|
- end message: the name the request hashed into a fixed length word with _END_.
|
|
|
|
|
|
The messages or chunks are sent through the stream. After the message reading, the read handler name allows to dispatch it to the correct handler. The *StreamDispatcher* object is responsible for collecting and forwarding the message to the correct handler. There is one *StreamDispatcher* on the client side and as many as clients on the server side.
|
|
|
|
|
|
#### Limitations and improvements
|
|
|
|
|
|
For big data, we do not know the number of chunks that will be sent to the client (the chunks are read from another file stream). Then the current protocol searches in each chunk the presence of the end sequence by comparing the bytes. When it is found, the response is considered finished.
|
|
|
However in case of a binary response, there is a small probability that a message contains the end sequence whereas it is not the end sequence.
|
|
|
One solution:
|
|
|
- start message: the name the request (can be hashed)
|
|
|
- content messages interleaved with status messages: the status message tells if there is more data or not.
|
|
|
In that case, the end message is a status message and the receiver can check only the status messages.
|
|
|
|
|
|
A message is cut into chunks that are sent through the stream. When the message is read, the handler name read allows to dispatch it to the correct handler. The *StreamDispatcher* object is responsible for collecting and forwarding the message to the correct handler. There is one *StreamDispatcher* on the client side and as many as clients on the server side.
|
|
|
#### Main components
|
|
|
|
|
|
AssetGetter: The object is getting the 3D model data. It registers handlers on the *StreamDispatcher* and when data are fetched they are stored in the *IndexedDB* browser database using the *AssetStorage* object. On the server side the *AssetResponder* is reading the data on disk.
|
|
|
|
... | ... | |