Difference between revisions of "Protocol Design"
Warning: preg_match(): Compilation failed: group name must start with a non-digit at offset 8 in /www/htdocs/w0102f68/fos/wiki/includes/MagicWord.php on line 902
From FOS Wiki
m (explained the type property) |
(Introduced the basic concepts of the protocol) |
||
| Line 1: | Line 1: | ||
| − | = | + | = Basics = |
| − | The communication is based on | + | The hole communication is based on a TCP/IP connection. |
| + | The server and the client communicate to each other through UTF-8 encoded messages. | ||
| + | |||
| + | == Message == | ||
| + | A message is a json encoded object. Each message has a common "type" property, which determines it's type. | ||
| + | The message ends with the determination of the json object: <code>}</code>. | ||
| + | |||
| + | = Session = | ||
| + | To start a session the client must send a valid username and password encapsulated in the json object "Login". | ||
| − | |||
[[File:protocol-login-logout.png]] | [[File:protocol-login-logout.png]] | ||
| + | |||
| + | = Dynamic Data (Server ⇒ Client) = | ||
| + | |||
| + | The protocol design is ''not'' based on a request-response concept. It's based on a concept similar to the model-view concept. The idea behind is: On login the client receives the current data: all locations, all tables, all orders, all products, ... . On each change of the data on server-side, the client gets an ''update''. The goal is to have a valid (up-to-date) data pool all the time on every client. | ||
| + | |||
| + | To achieve this, it's necessary to have id-value based data structures - to be able to identify a data set in an update. | ||
