A way to connect two spinneret's from anywhere in the world...
Bean
Posts: 8,129
I've noticed that many people that connect microcontrollers to the internet are disappointed that they can only be "seen" by other devices on their local network.
In fact most devices cannot be "seen" by the outside world without getting a static IP and configuring your router to do port forwarding.
Most people don't have a static IP address, and if they did they have no idea how to setup port forwarding. And what about using networks away from home. At your work, or a public WiFi ?
I think I have come up with a solution. A relay server that will allow any two devices on the internet to communicate.
All you have to do is have any two devices anywhere on the internet make a connection to the server using IP address 72.95.9.104 and port 23 (telnet). Any data sent from the one device will be sent to the other.
You can also use telnet on a PC as one or both of the devices, it works the same.
Right now it just relays the first two devices that make a connection, but eventually it will be setup so it knows what mac addresses should be relayed.
Let me know if you have any comments about this idea, and if you try it.
Thanks, Bean
In fact most devices cannot be "seen" by the outside world without getting a static IP and configuring your router to do port forwarding.
Most people don't have a static IP address, and if they did they have no idea how to setup port forwarding. And what about using networks away from home. At your work, or a public WiFi ?
I think I have come up with a solution. A relay server that will allow any two devices on the internet to communicate.
All you have to do is have any two devices anywhere on the internet make a connection to the server using IP address 72.95.9.104 and port 23 (telnet). Any data sent from the one device will be sent to the other.
You can also use telnet on a PC as one or both of the devices, it works the same.
Right now it just relays the first two devices that make a connection, but eventually it will be setup so it knows what mac addresses should be relayed.
Let me know if you have any comments about this idea, and if you try it.
Thanks, Bean
Comments
This sounds interesting. It's similar to what Jump Desktop is doing with VNC and RDP. They use Google mail to exchange information to link the computers together. I use it on my PC's and phones and tablets to get remote access. It works well.
You could do similar with telnet or your own HTTP API or anything that is efficient to implement on the prop and secure.
Sounds like something fun to play with and build!
I have a NearlyFreeSpeech "server" sitting out there in the "cloud" I'd be willing to donate to R&D. I may need to reconsider the donation once this becomes a hit and I can't afford the traffic charges!
I think Bean is trying to avoid this step from most dynamic IP services:
Lots of people that don't know or don't want to know how to port forward through their router but could play with remotely connected stuff.
Computer Home - The computer that you want to connect to at any time.
Computer Remote - The roving computer that you want to use to connect to computer home.
Computer Server - The intermediate server (must have a static IP).
1. Connect Computer Home to Computer Server with a reverse SSH tunnel: 2. Connect Computer Remote to Computer Server with normal SSH.
3. Via the connection from 2, connect (SSH) to port 33221 on local host, with username and password from Computer Home.
At the end of this, you have a transparent SSH tunnel from your Computer Remote to your Computer Home.
1. Have a simple internet device (eg spinneret or similar) plugged into their home internet. Often/mostly this is a dynamic IP address.
2. Connect remotely - probably via an iPhone or Android phone/tablet (using the web browser) or any computer (using the browser) on the internet.
3. Command the home device to switch pins (ie turn lights, etc on/off) or to return the status of some pins (eg, door closed, cat inside, etc)
I don't know much about the internet and nothing about SSH.
So the questions are...
4. How to solve the dyamic IP address.
5. How to access the home device and a method to turn on/off or receive status.
I think it's quite common that users with internet access at home are given a small web storage for home use by their providers. Could this be used to provide the dynamic IP address?
I don't have a landline. My internet is provided by the cellular phone (data 3G & 4G) network. But I do have my own website which of course has a static IP address.
6. What I mean is, can you create a simple web page that could receive and then provide access to the dynamic IP address?
7. Could this arrangement be setup as a standard web page format that could easily be copied by unfamiliar users?
This is done for the arduino by using the website www.teleduino.org
I don't know if i works for other microcontrollers.
Maybe I could setup something similar ???
Bean
Oh you could save the telnet session to a log, and have another telnet session parse that log and output it. Rudamentary but would be fun to test.
You could just use a plain telnet server and give out accounts tiny accounts on it like an FTP server. For each group of robots that wanted to connect they could all share the same username and password. Then they would all have access to the same files. The robot could use filenames on the telnet server to communicate. When the last robot in the command address reads the command it erases it.
The file name format could be like aaa.bbb.ccc.ddd
a= from
b= to
c= command
d= time to live
You can run a script locally on the machine to clear out the time to live expiries.
Actually that is kinda cheesy. Another really quick way to get this running would be to use a telnet chat server. Just have the telnet chat server available to the public and let the robots "chat" with eachother.
My thought was to register the MAC addresses.
Then the server would know what connections to send the data to.
When it receives data from one MAC address, it relays it to all connected MAC addresses in that registered group.
Bean
-Tor
I didn't think it worked that way....Hmmmm I guess I'll have to re-think that idea.
Thanks for the info.
Bean
I think the idea here is to use the MAC address only as a unique end point identifier in this relay application, not to use the MAC address in its traditional sense as the identifier of an interface on a local network segment. The MAC is a guarantee of endpoint uniqueness (unless you are cheating) but I don't know if it has any advantage over any other less cumbersome to use and remember arbitrary ID you choose to use for your little network.
I was assuming you would keep all your little connections private but I guess you could share an endpoint if you wanted to or needed to.
Most services like this generate a private key that you use to connect to your endpoints.
This gets more complicated when you decide to commoditize a service like this.
User sends a command message to an email address and the spinneret retrieves the message, carries out the command and sends an email back with current status. Depending on the email server the transaction could be completed in near real time.
I used this technique to 'chat' with a friend of mine a couple of times. I was working on a ship and we weren't allowed access to any of the normal chat sites due to bandwidth considerations. The conversation certainly wasn't real time but it was interactive.
Sandy
I like the idea of the two devices being able to check in, or check for messages. It would be great to provide a path between two devices, but you would want the ability for them to be able to communicate even when they are not connected to the service simultaneously.
Like Alexander said a messaging system would be great. Robot A is connected to the server and sends robot B a message, robot B shouldn't have to be accepting connections at the time to get the message. The message should wait for robot B to login, or robot A to modify it. That is why I was initially thinking you could send messages by changing file names.
Then for real time communication something like echoing one session to another would work great. In a telnet chat room scenario you could make it impossible for the client to see a user list. They could join the sessions under the same username and password to echo the commands between just those sessions.
So when can I log in?
The problem is to know which internet IP address is currently assigned to your router. Here a server in the internet helps. Just have this little PHP script running on the web-server:
<html> <body> <?php $ip = @$_GET["saveIP"]; if( $ip ) { try { $stream = @fopen("ipadr.txt","w"); fwrite( $stream, $_SERVER['REMOTE_ADDR'] ); fwrite( $stream, "\n" ); fwrite( $stream, $ip ); fclose($stream); } catch ( Exception $ex ) {} } $string="Fnf"; try { $stream = @fopen("ipadr.txt","r"); if( $stream ) { $string = stream_get_contents($stream); fclose($stream); } } catch ( Exception $ex ) {} echo $string."\n"; ?> </body> </html>Your spinneret would simply call this page periodically adding a ?saveIP to the URL of that webserver. This script then stores the IP-address of your router in a file. Of course it could be improved to check a key before .... at least I'd add a user to the .htaccess of that location .
From everywhere in the world you can call the same URL without the parameter to see the IP address of your router.
This is best case scenario ;o) Worst case is, that your internet service provider does not assign real internet addresses to your router, but IP addresses out of the private range. Here the only solution is to have a full proxy in the middle. It should also be possible to allow a point to point connection when tweaking the packages a bit. But it would be neccessary to poll for connection requests.
A nice solution in this case would be to add a GSM-module to your spinneret! It could send text messages to your mobile in case of an alarm and you can send a text message to it in case it should go online. Just a simple prepaid contract ...
My Xoom replaced my previous USB 3G dongle and I set it up to be on most of the day as a hotspot.
My iPhone can also be setup as a hotspot.
If I leave my Xoom on permanently (which I can do) or I used a small 3G/4G router permanently on, then I have a hotspot at home (or on my boat). It seems that 4G is getting close to replace wires to your home (it is actually faster here in AUstralia than most home connections via copper). In Oz we have begun rollout of fibre to the home - IMHO this is a waste so late in the game as I see wireless taking over completely, with Telco WiFi (new bands) at the street corners to service local homes.
Anyway, this is OT, so back to the topic at hand...
Most phones these days have internet capability with a browser, so I see that as the control method of choice for the future. Therefore, any box at home needs to interface this way. Perhaps a simple way is to interface the Prop to one of the ~$20 WiFi hubs such as hacked WR703N.
So how do the police determine what computer has "hacked" a site ? There must be a way. I mean the data gets back to correct computer.
Bean
-Phil
Web API Tutorial:
http://www.asp.net/web-api
The message service is very basic and very extensible. It takes advantage of RESTful services which is ideal for an embedded web server. IMO, REST services are easy to implement since they do not require a ton of processing logic.
Two interfaces define the service
1) Subscription Services
2) Message Services
A device wanting to subscribe sends an HTTP POST message to localhost/api/Subscribers/. The HTTP request body is an XML document containing the the device's IP, Port and username. The ID is assigned after a successful registration.
<Subscriber xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/AgaveRobotics.Web.Demos.Model"> <Id>0</Id> <Ip>192.168.1.104</Ip> <Port>13000</Port> <Username>W5200</Username> </Subscriber>Once registered, a user can send a message to service subscribers. Sending a message is an HTTP POST to localhost/api/Messages/
<Message xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/AgaveRobotics.Web.Demos.Model> <Id>1</Id> <From>spinneret</From> <To>W5200</To> <Content>Hi W5200 from Spinneret.</Content> </Message>Take a look at the attached W5200 for the QuickStart achieve. It contains the the literal POST and header info.
For the interested, there are a few nuggets in the messaging project. The subscription service using a singleton pattern. All services interfaces implement the repository pattern. There's room for further service abstraction using Inversion of Control (Dependency Injection).
I had a lot of fun building this project. I hope it inspires folks.
However, a device can poll the message stack for new messages.
I'm not sure what you mean by robot ID please elaborate.