================== TWXSync XML format ================== Introduction ------------ This is a first draft of the TWXSync communication protocol. All TW data structures will be common with the TWX v2 file format. The XML format described here should is sent compressed using the well known compression standard (ZLIB). Encryption of the data could be a future enhancement. Overview -------- The general XML syntax for the communication: ### Client ### ... ### Server ### ... (When the server want to push something to the client, like an update, the roles are reversed) The Session tag describes which session it is. Since this is a client/server solution, we should start by logging in and this tag will then be used to identify the rest of the communication. (Theoretically it would be possible to have multiple sessions) The Command tag tells the server what the client wants to do. It may contain additional attributes and data tag structures depending on the command. The current list of command tags: Login, Request, Create, Update The server will respond with a Result tag that contains a HTTP like return code and the corresponding text version. If the command executed successful, the code will be 2xx otherwise 4xx or 5xx. The result tag may also contain additinal data tag structures depending on the command. See this link for codes: http://www.cybraryn.com/support/resources/internet/httpstat.asp Use cases --------- Here are some use cases with different commands and possible results: 1. LOGIN and create a session. Here we can place some authentication if we want to validate the user. The client should create a unique id, a 128-bit GUID, that will identify the client. NOTE: Since this is the first client request, so we don't have a session tag. The response from the server contains the session tag if the login was successful. The client should use this in all future communication in this session. ### Client ### ### Server ### or or 2. LOGOUT is done by calling void TWC_TWXSync_Close(long hTWXSync); 3. REQUEST the list of games the server is currently hosting. Each game is given a unique 128-bit GUID by the server when created. The Game tags contains a data tag structure describing the game like how many sectors, the host address/port and other info. When requesting, we do not care about the session Id of the client. ### Client ### ### Server ### Game A 5000 Game B 20000 --- THIS IS NOT SUPPORTED --- 4. CREATE a new game on the server. This would have to be done if the game you are currently in does not exist on the server yet. The server will generate a unique 128-bit GUID as game id. ### Client ### ... ### Server ### --- END UNSUPPORTED SECTION --- 5. UPDATE data in a game when we know the game id. This request can be done by both the client and the server. The client will send it when new data is discovered and the server will send it when other clients have updated something that needs to be pushed out to the client. The data could be any of the data structures used in the TWX v2 file format. Extensions should be made to both formats. ### Client ### 1820 2702 2944 ### Server ### 6. WHEN first connected, the client would want to request the old updates that has occured since the last time it was connected to the server. It would then simply send a Request command and ask for all updates between two dates and all that info will be sent from the server. If the type is missing it means all kinds of information. If the begin date is missing it means start from the very beginning. If the end date is missing it means up till now. ### Client ### ### Server ### 1820 2702 2944 4820