Differences

This shows you the differences between two versions of the page.

--- webapi:implementations:udp [2025/01/30 08:27] – created icke_siegen
+++ webapi:implementations:udp [2025/01/30 08:59] (current) – icke_siegen
@@ Line 1: / Line 1: @@
 ~~HEADLINE NUMBERING FIRST LEVEL = 3~~
-Titan Web-API
+Titan WebAPI
 ====== WebAPI over UDP ======
-By design, the Web API works with HTTP requests - and HTTP is bound to TCP (this is about network protocols - if you don't know what this acronyms mean then this topic isn't interesting for you :-)). You may come across situations where you need to control  Titan from UDP requests, e.g. when working with particular main control suites.
+By design, the Web API works with HTTP requests - and HTTP is bound to TCP (this is about network protocols - if you don't know what these acronyms mean then this topic isn't interesting for you :-)). You may come across situations where you need to control  Titan from UDP requests, e.g. when working with particular main control suites.
 While it is not possible to simply fire the same request as UDP string onto Titan, it is very well possible to run a little program like socat, which - when started with proper parameters - forwards UDP strings as TCP requests. The only other thing is that you need to send a complete HTTP request string.
@@ Line 18: / Line 18: @@
 The parameters I used are
-  * udp4-listen:9090  -- this tells socat to listen to UDP messages, on port 9090, in IPv4 protocol
+  * ''udp4-listen:9090''  -- this tells socat to listen to UDP messages, on port 9090, in IPv4 protocol
-  * reuseaddr  -- allowas other sockets to bind to the same address (I found this helps avoiding some issues)
+  * ''reuseaddr''  -- allows other sockets to bind to the same address (I found this helps avoiding some issues)
-  * TCP:192.168.178.59:4430  -- this tells where and how socat forwards the messages to, in out case, as TCP requests, to the IP of the Titan PC (the same computer socat is running on), on port 4430 (the port Titan listens on)
+  * ''TCP:192.168.178.59:4430''  -- this tells where and how socat forwards the messages to, in out case, as TCP requests, to the IP of the Titan PC (the same computer socat is running on), on port 4430 (the port Titan listens on)
-When everything is setup properly then socat just sits there and does its job, without any visual feedback. However when debugging or looking for a particular issue it might help to start socat with some debug output, using the option -v
+When everything is setup properly then socat just sits there and does its job, without any visual feedback. However when debugging or looking for a particular issue it might help to start socat with some debug output, using the ''option -v''
   socat -v udp4-listen:9090,reuseaddr TCP:192.168.178.59:4430
-This outputs the transferred data to you screen, and help in finding possible faults.
+This outputs the transferred data to you screen, and may help in finding possible faults.
 You can also start socat with the hostname instead of the IP address, like this:
@@ Line 36: / Line 36: @@
   Ctrl-C
+{{:webapi:implementations:socat.png?600|}}
+==== - Send full HTTP request strings over UDP ====
+Now, as socat expects UDP messages and forwards them as TCP, and Titan expects full HTTP requests, we need to send full request strings. Otherwise there will be no result at all, or socat crashes. In my tests the a.m. option -v did help as it shows the reply from the Titan engine (here: Status 400 - Bad Request...).
+In order to send some UDP messages, either use your control suite, or - for tests - use a tool like PacketSender (https://packetsender.com/).
+{{:webapi:implementations:packetsender.png?600|}}
+The parameters to send as UDP are
+  * address: the IP address of the Titan computer (in my case 192.168.178.59)
+  * port: 9090 (the port which we told socat to listen to)
+  * method: UDP
+  * ASCII string: this needs to be the full HTTP request string, starting with GET, containing the API request itself, the protocol, host/port, and must end with two linefeeds:
+  GET /titan/script/Playbacks/FirePlaybackAtLevel?userNumber=1&level=1&bool=false HTTP/1.1\r\nHost: 192.168.178.59:4430\r\n\r\n
+**Only for readability** here is the same string wrapped into lines (but you need to send it as one string):
+  GET /titan/script/Playbacks/FirePlaybackAtLevel?userNumber=1&level=1&bool=false HTTP/1.1\r\n
+  Host: 192.168.178.59:4430\r\n
+  \r\n
+  - The first line starts with the HTML method (GET), and contains the API request (/titan/script/Playbacks/FirePlaybackAtLevel?userNumber=1&level=1&bool=false) and the protocol (HTTP/1.1)
+  - The second line defines the Host (IP address and port) - this is required to make it a valid HTTP1.1 request
+  - The third line simply contains a linefeed (strictly the second linefeed after the one at the end of line 2), in order to mark the end of the request.
+May this does not work for all Web API requests - but it is a starting point to make it available over UDP.