I ask this only as a general question becuse I don’t know exactly how the core obtains its IP from my router; I assume just like anyother wifi device - Requiest IP from DHCP server of the router but, what if the router was a wireless DHCP server ? with file storage ? assigning multiple IPs to my core; Is this possible ?
Here are my questions:
Can the spark core connect to more than 1 IP at a given time ?
Is it possible to connect 2 Spark Cores in a Peer to Peer setup over the cloud =
I have been following discussion on webhooks (not that I understand a lot of that discussion) so I will wait until this has been implemented.
Have you worked any with the Spark API code itself ?
I have been doing some reading on Restful API and does not seem to complicated in handling security and HTTP requests (most of them at least ) ? And, with my simple mind I think, “How hard can it be to develop a local Restful API where I can strip requests and return responses to my browser ?” (Awfully Hard - but I am trying.)
I’m sure you’re right about the Spark Core with it’s current software, and sorry to be picky, but you can associate more than one IP address with one network interface.
Also, for two Spark Cores to communicate there is no need for any special CC3000 functionality. Already this is easy enough using TCP or UDP. The issue is how do two Spark Cores identify each other, how do they communicate their IP addresses to each other. Already this can be done at the application level on your LAN. Broadcast a UDP packet saying “I’m a Spark Core, my Spark ID is x and my IP is y.” [You only need give your IP address because this cannot reliably be discovered by the recipient on Spark UDP owing to it being buggy.]
I guess the forthcoming webhooks facility will provide this as part of the Spark Cloud and then two Spark Cores won’t need to be on the same LAN to discover each other, and no UDP messing about will be required.
But pending that @spydrop could get his Cores all on the same LAN talking to each other in the way I describe. My Cores intercommunciate but I’ve told the local nameserver the MAC addresses of my Spark1, Spark2 etc and so the discovery process needs not be programmed even though the IP addresses are not fixed.
First, @psb777, thanks for all that good infrormation as that is helping me and I am sure others understand more about the core network connectivitity.
@peekay123, posts by @NaAl and their videos show how they are using, just like @psb777 stated above, UDP / TCP via a Websocket to communicate directly with the Spark Core without the cloud. And I will have to learn more about how to do that exactly.
@peekay123, Can I use this homing process you speak of in this manner: (with 2 IP - Port connections)
1.? Use a PHP Websocket to create a connection to my core at (for example) IP/port 2585 to establish a proper network connection for my core to be served an IP lease from my routers DHCP server.
and then
2.? Have my core run Tiny Webserver to establish IP/port 80 to serve up a webpage .
@kennethlimcp, yes 1 IP / 2 ports is okay with me, if it allows me to run a webpage from the Core without being connect to the cloud.
There are many examples and code in both PHP & Java for UDP servers so this opens a lot for users to take complete control of their cores. And, Just like you experienced last night with the “Now you see the pages - No you don’t see them Sparkulator Bug” sometimes being off the internet works best.
And then there’s the real reason I want off the internet and that is (drum roll) !!! Check out this scenero.
I buy a mini Android PC which has 8GB of storage space and IP Camera Attached for about $100 USD
I buy a miniture wifi Router. $30
I use Nuttix RTOS to communitcate with the Android PC.
I can run a UDP Server on Nuttix to communicate the IP Camera feed via the wifi Router to a wifi remote display.
My core will run Tiny webserver and hold all the HTML and parse it to my Broswer / Android Tablet.
I place all of this on a large scale RC Semi Truck & Trailer with a large LiPo Battery for Core, etc.
I place a drone on the back of the RC Semi-Trailer to be remotely launched and controlled from a distance.
This a function to broadcast a datagram to the local LAN. If you substitute a specific address then it only goes there. I’m unsure if the bug has been fixed whereby the UDP socket is required to be closed and re-opened every 60 secs, but this code does do that. I’m not sure a begin() and a stop() are even needed for broadcasts, but I have been doing it anyway. Note that a Spark UDP bug means the recipient will not be able to determine the end of the datagram, so you will need to ensure that buf has a newline or other delimiter. Also note its one datagram per send() with a max length of 576 bytes, do not attempt to send one longer message by splitting it into two as (a) you cannot rely on the datagram being received once, it could be received zero or multiple times and (b) and the ordering of the datagrams is not necessarily maintained. For a a reliable datastream of arbitrary length you should use TCP but then you cannot broadcast - it has to be end to end, 1 to 1, a connection.
void UDPsendString( char *buf) {
static unsigned long gul_udp_begin_millis = 0;
static int gb_udp_open = 0;
IPAddress remote_IP( 255, 255, 255, 255); //to broadcast to the entire LAN
//IPAddress remote_IP( 192, 168, 1, 101); //dc5800
unsigned int remote_port = 32001;
unsigned int local_port = 32002;
static UDP gudp;
// Bug on Spark where udp must be re-opened at least every minute
if( gb_udp_open && millis() > gul_udp_begin_millis + 50000UL) {
gudp.stop();
gb_udp_open = 0;
}
if( ! gb_udp_open) {
gudp.begin( local_port);
gb_udp_open = 1;
gul_udp_begin_millis = millis();
}
gudp.beginPacket( remote_IP, remote_port);
gudp.write( buf);
gudp.endPacket();
return;
}
spydrop, I don't believe the CC3000 supports multi-homing but as kennethlimcp points out, TCP/UDP is designed to use multiple "ports" (up to 65535!) on a single IP. In your case, the CC3000 uses special UDP ports to talk to the DHCP server and get an IP allocation as per the RFC 1531 standard. The DHCP process is done automatically as part of the WiFi-to-Router handshaking (assuming you have not set a static IP). So I am not sure what you mean by:
When your Spark gets its IP, you can open any valid TCP or UDP port you wish. So one IP but multiple ports allows an external client to access multiple "services" on your Spark. If you look at the TCP/UPD standards, there are a number of pre-defined ports/services for things like SMTP (simple mail transfer protocol, port 25), RDP (remote desktop, port 3389), etc.
Thanks for this as I was confused about the connection and access shemes used by the Core.
So if I am understanding the wifi-to-Router Handshaking, once the Core is assigned IP via a websocket server I can access port 80 and connect to Tiny Webserver that resides on my Core.
Lots to learn but, now I am closer to a “off the cloud” solution for my product & other projects.
