TINXL/tinxld

tinxld is a daemon that will run on the device, and provide the interface between applications and the main TINXL server.

It will run locally only, on port 1337, where applications will be able to connect to it. The protocol it uses will be text-based, and hopefully should be relatively simple for anyone to understand.

Protocol Plans

when program is started running, connect to tinxld tinxld sends a request for info every 1 - 5 minutes to any programs connected to it's port. The program should then reply with a CSV of program data, first sending the required data:

• program id
  • Each program with tinxl support will be given a 10 character application id, which is how it is identified at the tinxl server.
• program version
  • There will be support for differing versions of programs, and support for a compatibility matrix on the server end, to allow the program's creators to mark versions that will and will not work together.
• program mode
  • This will be an integer / short string which is mapped at the server side to a mode. For example, an application would only have a 'default' mode, an emulator could have a 'single' and a 'multiplayer' mode, and an fps game could have 'single', 'deathmatch', 'co-op' and other modes.

Once these pieces of information have been sent, an application can send any other pieces of information they please, such as:

• rom / level / map name / id
• rom / map hash
  • provides md5 of current rom / level, to allow matching of versions if necessary)
• server
  • dotted quad / fqdn / localhost (server will perform lookup of IP it sees the request as coming from localhost, or if the ip address is on a LAN (192.168.x.x, 10.x.x.x etc), useful for people behind routers who might not know their outward-facing ip)
• port
  • integer representation of the port the server is running on.

This data will then be sent along with any other data in the buffer to the main TINXL Server, using xml over HTTP, along with some kind of computationally cheap checksum. The server will either respond with a 403 for a failed checksum, or a 200 for ok, also sending back any new data that is waiting at the server end.

tinxld will then send a broadcast message to any connected applications, notifying them that there is a message / request pending.