SATP

SATP

SATP stands for «String Array Transfer Protocol». Here I will give description of SATP 1.0, and then new features of SATP 1.1 will be introduced.

Command: ADD \<name>
Source: client
Reaction: If server is busy (current session exists) – check how long does it last. If less than 10 seconds have passed from its start, send BUSY response and disconnect
Otherwise, search for graph \<name> in the storage.
If graph with such name exists – send NAME ALREADY EXISTS response and disconnect
If \<name> is an empty string – send NAME REQUIRED response and disconnect
Otherwise, start new session with the name \<name>, save current timestamp as the time of its creation. If the entire data array will not be received within the next 10 seconds, server will reset this session as soon as another client sends ADD command. If there are no other candidates for data transmission, duration of the data receive process is not limited.
Then send DATA SESSION STARTED response

Command: DATA#\<data>
Source: client
Reaction: If there is no open session, send NO OPEN SESSION response and disconnect
Otherwise, add string \<data> into the buffer (for example, a vector)

Command: END
Source: client
Reaction: If there is no open session, send NO OPEN SESSION response and disconnect
Otherwise, add buffer contents into the storage, put session name into the hash-map, linking it to graph position in the vector. Reset session, send OK response

Command: GIVE \<name>
Source: client
Reaction: Search for graph \<name> in the storage. If graph with such name exists – send data string by string. Finally, send END response
If there is no such graph - send NOT FOUND response and disconnect
If \<name> is an empty string – send NAME REQUIRED response and disconnect

Command: CHECK \<name>
Source: client
Reaction: Search for graph \<name> in the storage. If graph with such name exists – send NAME ALREADY EXISTS response and disconnect
If there is no such graph - send OK response and disconnect

Command: LIST
Source: client
Reaction: Send all names in the storage one by one. If the storage is empty, do not send anything. Then send END response and disconnect

Command: DELETE \<name> \<password>
Source: client
Reaction: If \<name> is an empty string – send NAME REQUIRED response and disconnect
If \<password> is an empty string – send PASSWORD REQUIRED response and disconnect
Search for graph \<name> in the storage. If graph with such name is not found - send NOT FOUND response and disconnect
Check if the provided password is correct. If it is not - send INCORRECT PASSWORD response and disconnect
Otherwise, delete graph with the name \<name> from the storage, remove \<name> from the hash map. Then send COMPLETED response and disconnect

Command: NAME ALREADY EXISTS
Source: server
Reason: Name is already in use
Reaction: Require another graph name from user

Command: OK
Source: server
Reason: Operation successful/name is available

Command: DATA SESSION STARTED
Source: server
Reason: Data transmission is permitted

Command: BUSY
Source: server
Reason: Server is busy
Reaction: Ask user to try again later

Command: INCORRECT PASSWORD
Source: server
Reason: Password is incorrect
Reaction: Notify user that the password is incorrect

Command: NO OPEN SESSION
Source: server
Reason: Attempt to transmit data without opening session/attempt to close unexisting session

Command: END
Source: server
Reason: End of data

Command: BAD REQUEST
Source: server
Reason: Request is not supported

In SATP 1.1 request CHECKVER was added. Versions of GES since 1.1 provided version number as a response. Also format of commands ADD, DATA and END was changed. Here is the description of the new format of these commands: (parameters in square brackets are optional for backward compatibility):

Command: ADD \<name> [key]
Source: client
Reaction: If server is busy (current session exists) – check how long does it last. If less than 10 seconds have passed from its start, send BUSY response and disconnect
Otherwise, search graph \<name> in the storage.
If graph with such name exists – send NAME ALREADY EXISTS response and disconnect
If \<name> is an empty string – send NAME REQUIRED response and disconnect
Otherwise, start new session with the name \<name>, save current timestamp as the time of its creation. If the entire data array will not be received within the next 10 seconds, server will reset this session as soon as another client sends ADD command. If there are no other candidates for data transmission, duration of the data receive process is not limited.
If [key] is not provided set session key to zero, else - set it to [key] value
Then send DATA SESSION STARTED response

Command: DATA#[num]#\<data>#[key]
Source: client
Reaction: Add string \<data> into the buffer at position [num] (if [num] parameter is not provided, append it to the end of the buffer)
If session key is not zero, check [key] parameter. If it is not provided or it is not equal to session key, send ACCESS DENIED response and disconnect
If there is no open session, send NO OPEN SESSION response and disconnect

Command: END [key]
Source: client
Reaction: If session key is not zero, check [key] parameter. If it is not provided or it is not equal to session key, send ACCESS DENIED response and disconnect
Otherwise, add buffer contents into the storage, put session name into the hash-map, linking it to graph position in the vector. Reset session, send OK response

New version of the protocol also recommends data verification on the server side with the respection to the string indices.
If data errors are found during verification, server may send DATA ERROR response for DATA request and terminate the session.
So, two new server responses were also introduced in SATP 1.1 - DATA ERROR and ACCESS DENIED

Introduction of indices allows clients to transmit strings without delays between them, but lead to several problems on server side (thread that processed END command might finish before threads, reading real data; first string, that contains total lines number might be processed too late, etc.). These problems were being solved with variable success, finally most of them were completely solved, frequency of others was minimized. Apparently, one of the last solutions for timely thread execution uses thread interaction mechanisms of Java and method join(), that makes one thread wait for another thread to finish, which is the most reliable and appropriate variant. Also repeating parsing attempts with delays on server side were used (so-called retry blocks).

Introduction of keys protects session from unexpected "third-side" termination, and to prevent data falsification. Server side data verification is especially important here, because number of processed lines is also checked. In case of falsification attempt fake data will come with the real one, which will inevitably lead to data error.

Data verification is useful even in backward compatibility mode, because it sometimes helps to detect line order violation on base of the data format before saving data to the storage. It helps to minimize the probability of appearence of corrupt unreadable data on the server.