HTTP to socket API

This is an HTTP based API that allows for the use of TCP and UDP sockets in vanilla CC without the need for any custom peripherals. A lua wrapper for the API was done by Cloud Ninja. All data returned by the API is in UTF-16BE encoded XML. Since it returns UTF-16BE encoded strings I also included a CC api for turning it into ascii. The application is shipped as a java WAR(download link below) and can be deployed in any servlet container i.e. apache tomcat. If there is enough interest and people are willing to donate I might set up a server for public use. When a socket is opened XML will be returned in the following format(note the ID is not always 0):

<?xml version="1.0" encoding="UTF-16BE"?>
<credentials>
<id>0</id>
<passwd>assignedpasswd</passwd>
</credentials>

Calling the receive function tells the server to wait for an incoming packet but since the amount of time till the packet arrives is unknown it will instantly return no data. You must call query to get the data received if any. Calling receive, query, and close is identical for both UDP and TCP connections.
When you query data it will return the following XML for TCP:

<?xml version="1.0" encoding="UTF-16BE"?>
<packet>
<data>packet contents</data>
</packet>

UDP will return slightly different XML:

<?xml version="1.0" encoding="UTF-16BE"?>
<packet>
<address>127.0.0.1</address>
<port>1234</port>
<data>packet contents</data>
</packet>

I've listed below how each function would be used. Please note that the data parameter containing the message to be sent must have all characters properly escaped. I.e using %20 instead of a space.

Open a TCP socket to the freenode IRC server:
local data = http.get("http://example.com/http2socket.jsp?protocol=tcp&address=irc.freenode.net&port=6667")

Open a UDP socket:
local data = http.get("http://example.com/http2socket.jsp?protocol=udp")

Send a TCP packet:
http.get("http://example.com/http2socket.jsp?action=send&id=0&passwd=assignedpasswd&data=message")

Send a UDP packet:
http.get("http://example.com/http2socket.jsp?action=send&id=0&passwd=assignedpasswd&address=127.0.0.1&port=1234&data=message")

Receive a packet:
http.get("http://example.com/http2socket.jsp?action=receive&id=0&passwd=assignedpasswd")

Query for a received packet:
local data = http.get("http://example.com/http2socket.jsp?action=query&id=0&passwd=assignedpasswd")

Close a socket:
http.get("http://example.com/http2socket.jsp?action=close&id=0&passwd=assignedpasswd")

WAR Download
utf2ascii API: https://bitbucket.org/Scoopta/utf2ascii
Cloud Ninja's lua frontend: http://pastebin.com/m7JNrRa3
The lua wrapper provided by Cloud Ninja has all the documentation required commented out at the top as well as having a copy of the utf2ascii API internally.

Computercraft already emulates UDP and if you're interested in in-game TCP, you should check out RFC 793 and see how you can apply it to CC.

Whilst you have an interesting project, what's it for?

CrazyPyroEagle, on 08 July 2016 - 09:38 AM said:

Computercraft already emulates UDP and if you're interested in in-game TCP, you should check out RFC 793 and see how you can apply it to CC.

Whilst you have an interesting project, what's it for?

This project allows for real TCP and UDP communication out to the internet. One example is creating an IRC client in CC and connecting it to freenode or any real IRC server. In theory you could use it to connect to any real server.

It sounds useful but most servers on the internet support HTTP or HTTPS nowadays.

CrazyPyroEagle, on 08 July 2016 - 10:13 AM said:

It sounds useful but most servers on the internet support HTTP or HTTPS nowadays.

I think you're missing the point. This application is a JSP that can be deployed to a web server to provide an API accessible from CC via HTTP. The API provides access to TCP and UDP sockets allowing you to build software in CC capable of true networking. Some examples would include IRC clients, IRC bots, email clients, XMPP clients, telnet clients, among a million other things. Basically you can build a client for any network communication making use of a plain text protocol. Compared to CC without the API the only thing that could be done is building a web browser or fetching other web based content. I also think you have a misunderstanding of what HTTP is. HTTP is a protocol built on top of TCP. In fact the large majority of application layer internet communication is built on top of either TCP or UDP. A notable exception would be ping which is built on top of ICMP.

Scoopta, on 08 July 2016 - 10:39 AM said:

CrazyPyroEagle, on 08 July 2016 - 10:13 AM said:

It sounds useful but most servers on the internet support HTTP or HTTPS nowadays.

I think you're missing the point. This application is a JSP that can be deployed to a web server to provide an API accessible from CC via HTTP. The API provides access to TCP and UDP sockets allowing you to build software in CC capable of true networking. Some examples would include IRC clients, IRC bots, email clients, XMPP clients, telnet clients, among a million other things. Basically you can build a client for any network communication making use of a plain text protocol. Compared to CC without the API the only thing that could be done is building a web browser or fetching other web based content. I also think you have a misunderstanding of what HTTP is. HTTP is a protocol built on top of TCP. In fact the large majority of application layer internet communication is built on top of either TCP or UDP. A notable exception would be ping which is built on top of ICMP.

I think he does know, and he is trying to tell you, that there are many specialized APIs, that will serve you direct access to actions within IRC or email protocols.
I am sure, that HTTP to SMTP APIs exist already, so why do HTTP to TCP/UDP, when you have to implement the whole protocol in computeraft, making everything a lot more complicated.
I still think, there are some use-cases for some of the easier protocols, but making something more complicated, which is what this is for, is really easy to get wrong and I imagine debugging to be a hell.

So yeah, still a cool project, and I would love to see some projects utilizing this, but I don't think it's practical for more complicated stuff. Writing a specialized API is probably almost always the better, cleaner, and easier and more efficient architecture. The only true advantage of your approach is the exchangeability and easier deployment. Thats my opinion on that.

InDieTasten, on 08 July 2016 - 02:52 PM said:

Scoopta, on 08 July 2016 - 10:39 AM said:

CrazyPyroEagle, on 08 July 2016 - 10:13 AM said:

It sounds useful but most servers on the internet support HTTP or HTTPS nowadays.

I think you're missing the point. This application is a JSP that can be deployed to a web server to provide an API accessible from CC via HTTP. The API provides access to TCP and UDP sockets allowing you to build software in CC capable of true networking. Some examples would include IRC clients, IRC bots, email clients, XMPP clients, telnet clients, among a million other things. Basically you can build a client for any network communication making use of a plain text protocol. Compared to CC without the API the only thing that could be done is building a web browser or fetching other web based content. I also think you have a misunderstanding of what HTTP is. HTTP is a protocol built on top of TCP. In fact the large majority of application layer internet communication is built on top of either TCP or UDP. A notable exception would be ping which is built on top of ICMP.

I think he does know, and he is trying to tell you, that there are many specialized APIs, that will serve you direct access to actions within IRC or email protocols.
I am sure, that HTTP to SMTP APIs exist already, so why do HTTP to TCP/UDP, when you have to implement the whole protocol in computeraft, making everything a lot more complicated.
I still think, there are some use-cases for some of the easier protocols, but making something more complicated, which is what this is for, is really easy to get wrong and I imagine debugging to be a hell.

So yeah, still a cool project, and I would love to see some projects utilizing this, but I don't think it's practical for more complicated stuff. Writing a specialized API is probably almost always the better, cleaner, and easier and more efficient architecture. The only true advantage of your approach is the exchangeability and easier deployment. Thats my opinion on that.

Oh. Well if that was what he was saying then I completely missed that. I know I'm a little crazy but I personally avoid 3rd party APIs so all of the applications I write directly handle the protocol. I know…I'm crazy. This API might not be super useful to most but it has its use cases.