Hello!
Whats the most reliable way to implement a test within your sketch to see IF the cc3000 Server instance is ALIVE and accepting connections, and if not initiate a restart of the webserver instance being sure to destroy the previous one? Should you also restart the c3300 module as well or would this not be necessary?
Also is there any news on firmware or library updates on the cc3000 to increase its stability?
Its a great module, easy to use and cheap but it seems the general community consensus as well as my own testing shows there are some stability issues with the module which prevents it from being 100% reliable. In contrast, I have had the the W5100 ethernet shield running various webservers at home that have been up for over 6 months without any hint of instability.
cc3000 server library
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
-
adafruit_support_mike
- Posts: 67485
- Joined: Thu Feb 11, 2010 2:51 pm
Re: cc3000 server library
You can't really check TCP/IP status from within a single machine. All the tools to do it require a working TCP/IP connection, so your test would create a new connection within the machine (which is all but guaranteed to work) but wouldn't tell you anything about the network.
You can test TCP/IP connectivity by trying to ping a machine somewhere else on the network, but that's a 'tragedy of the commons' scenario waiting to happen. The more machines emit pings to make sure their connections are good, the more cluttered the network becomes and the less actual communication can happen. It's considered bad manners to ping someone else's network without express permission, but there are services that will ping into yours periodically.
In terms of single connections, there's kind of a Shrodinger's Cat thing going on.. TCP/IP builds reliable connections (TCP) on an unreliable network (IP), so gaps in the transmission and redunancy are normal. A machine sending data across the network keeps a list of "transmitted packet N, waiting for an ACK" records, and a machine receiving data emits "ACK packet N" messages for every one that arrives, no matter how many copies of packet N it's seen so far. The sender will transmit lots of packets before the first ACK can arrive, and will retransmit packets that haven't been ACK'd within a given time limit.
Statistically, that's guaranteed to transmit the entire message eventually.. for values of 'eventually' extending to infinity. In practice, machines usually give up after they've timed out a certain number of packets a certain number of times. The exact numbers and times are left as a judgement call for the implementer.
To confuse matters further, TCP assumes there will be gaps in the ability to communicate over the physical network. A dropped link-layer connection doesn't necessarily mean the TCP connection has failed. If you can re-establish the link within the timeout period you've chosen, the TCP layer will take the interruption in its stride.
The Adafruit_CC3000_Server library creates a socket that doesn't time out, so it's up to you to decide how to time out individual connections. There's no clear yes/no answer about whether a connection is still active until both sides explicitly negotiate the disconnection, just a set of factors you can weigh to decide when you've waited long enough.
A full solution within the machine would have "time since last ACK" counters for each connection that's opened but hasn't been closed, would periodically check cc3000.checkConnected() to make sure the wifi link is okay, and would probably shut down the wifi connection and restart it if there are no active connections and the time since the last restart was longer than some limiting value.
For additional confidence, you'd need an external machine to ping the server every so often, and have the server restart its connections if the time since the last ping exceeds some limit.
You can test TCP/IP connectivity by trying to ping a machine somewhere else on the network, but that's a 'tragedy of the commons' scenario waiting to happen. The more machines emit pings to make sure their connections are good, the more cluttered the network becomes and the less actual communication can happen. It's considered bad manners to ping someone else's network without express permission, but there are services that will ping into yours periodically.
In terms of single connections, there's kind of a Shrodinger's Cat thing going on.. TCP/IP builds reliable connections (TCP) on an unreliable network (IP), so gaps in the transmission and redunancy are normal. A machine sending data across the network keeps a list of "transmitted packet N, waiting for an ACK" records, and a machine receiving data emits "ACK packet N" messages for every one that arrives, no matter how many copies of packet N it's seen so far. The sender will transmit lots of packets before the first ACK can arrive, and will retransmit packets that haven't been ACK'd within a given time limit.
Statistically, that's guaranteed to transmit the entire message eventually.. for values of 'eventually' extending to infinity. In practice, machines usually give up after they've timed out a certain number of packets a certain number of times. The exact numbers and times are left as a judgement call for the implementer.
To confuse matters further, TCP assumes there will be gaps in the ability to communicate over the physical network. A dropped link-layer connection doesn't necessarily mean the TCP connection has failed. If you can re-establish the link within the timeout period you've chosen, the TCP layer will take the interruption in its stride.
The Adafruit_CC3000_Server library creates a socket that doesn't time out, so it's up to you to decide how to time out individual connections. There's no clear yes/no answer about whether a connection is still active until both sides explicitly negotiate the disconnection, just a set of factors you can weigh to decide when you've waited long enough.
A full solution within the machine would have "time since last ACK" counters for each connection that's opened but hasn't been closed, would periodically check cc3000.checkConnected() to make sure the wifi link is okay, and would probably shut down the wifi connection and restart it if there are no active connections and the time since the last restart was longer than some limiting value.
For additional confidence, you'd need an external machine to ping the server every so often, and have the server restart its connections if the time since the last ping exceeds some limit.
Please be positive and constructive with your questions and comments.