I inadvertently hit someone else's server when refreshing XXXX.localtunnel.com that I had left open in my browser (but since closed my tunnel). That was annoying.
Two suggestions:
1) Randomly assign subdomain names instead of reusing existing ones.
2) Increase the length of the subdomain from 4 characters to 6 characters. With 4 characters, each being a-z0-9, there are 36^4 subdomain possibilities. 36^6 would make it much more difficult to locate an active subdomain through trial and error.
I've used localtunnel quite a bit for quickly sharing a local dev server with a coworker and other things of that nature, but I noticed that after leaving a tunnel open for a while I would see requests from unfamiliar IP addresses.
It turns out this is because localtunnel reuses tunnel ids. Given how small the id space is, it's also possible that there are people who scan localtunnel URLs looking for interesting servers.
Keep this in mind before using localtunnel for anything you don't want the world to see.
An alternative way i've used to test Twilio till now is get a DynDNS account and point it to my home laptop. Infact my home router has a DynDNS option to fill in my username/password, so it can query the latest external domain assigned to it. This is useful if you're on a DHCP and don't have a static IP.
You get a domain like blah.ath.cx that you can use.
Nice. But isn't it time to just get yourself an IPv6 tunnel, and then be able to share anything that runs over the Internet instead of just one port? Then you can use the normal IP routing and access control machinery instead of having to roll your own.
The reason people don't bother with IPv6 is because it doesn't get them anything. But if you use IPv6 and share an IPv6-only-URL, then they'll finally have a reason to turn it on.
I was at the San Diego Ruby meetup group two weeks ago where one of the Twilio developers was on hand doing some demo work with the API. He was using this to tunnel the API / http calls through the firewall back to his local machine. Very impressive.
If minecraft clients can be configured to use HTTP proxies, you should be able to expose a minecraft server using PageKite; PageKite can handle arbitrary TCP streams, as long as the client knows how to initialize the connection with an HTTP CONNECT.
On the PageKite side, you'd register your minecraft server as a 'raw' backend. On the minecraft client, googling suggests this might be what you need: http://www.reddit.com/r/Minecraft/comments/fr2z9/how_to_get_... - you would tell it that the PageKite front-end is an HTTP proxy.
Two suggestions:
1) Randomly assign subdomain names instead of reusing existing ones.
2) Increase the length of the subdomain from 4 characters to 6 characters. With 4 characters, each being a-z0-9, there are 36^4 subdomain possibilities. 36^6 would make it much more difficult to locate an active subdomain through trial and error.
36^4 = 1,679,616
36^5 = 60,466,176
36^6 = 2,176,782,336