I need to program an esp8266 to do the following:
connect to a wifi network (station mode only)
start a server (udp) process to service requests
start a client (udp) to send roughly every 60 seconds
I am thinking on doing these actions on the setup() function:
create a timer to be triggered every 60 seconds.
start the udp server.
The idea is to "interrupt" the server with the timer and using the same port used on the server to send a udp packet to a remote location.
Example:
server is started to listen on port 2000. Then when the interrupt is triggered, the server should "pause", then we should send a packet from port 2000 to our remote IP, then the server should "resume"
I am waiting for my board to arrive to test this setup but wanted to know if that is possible. I am assuming that the mqtt client should work similarly (it can subscribe and publish). Aside from an interrupt I can't think on another way to "stop" the server temporarily and act as a client
Has anybody tried this before?
You should use the AT command
AT+CIPMUX=1
and
AT+CIPSTART=<link ID>,<type>,<remote IP>,<remote port>[,<TCP keep alive>]<link ID>
Related
I am using MQTT 3.1.1, I have installed a mosquito as a local server on my computer.
I am sending the Some sensors data from pubsubclient (MQTT client library ) to the mosquito and saving it to the database from the mosquito server
Whenever I start the session upto 5-10 minutes I am getting the messages but after that
MQTT client couldn't send any message and disconnect automatically.
Before disconnecting it prints the following message in command line
client <clientname> has exceeded timeout, disconnecting
Socket error on client <clientname>, disconnecting.
Also I am using the server with default configurations, except the QOS is set to 2
What is causing this error and
What should I do, so that client should not disconnect from my local server ?
The node(s) that is(are) Subscribing (and maybe the Publishing nodes if they take too long to Publish again) need the 'keepalive' field on the Connect call set. Most MQTT Brokers will timeout connections after something like 5 minutes, unless you have modified the timeout value in the settings.
Set the 'keepalive' option to something like 30 or 60 seconds will prevent the MQTT Broker from disconnecting. You Subscribers will start sending PINGREQ packets, and the MQTT Broker will reply with PINGRESP packets.
Read more here: http://www.steves-internet-guide.com/mqtt-keep-alive-by-example/
Imagine an MQTT broker with remote clients connected, which continuously send QoS 2 data - the standard situation. Clients are configured with "cleansession false" - they have a queue to send messages in case of a connection failure.
On the server, local clients subscribe to topics to receive messages.
Server load:
Launch the MQTT Broker
Running local clients
Connecting remote clients and receiving data from the queue
What if the third point occurs before the second? Are there standard solutions? How not to lose the first messages?
Assuming you are talking about all later reboots of the broker, not the very first time the system is started up then the broker should have stored the persistent subscription state of the clients to disk before it was shutdown and restored this when it restarted. This means that it should queue messages for the local clients.
Also you can always use a firewall to stop the remote client being able to connect until all the local clients have started, this would solve the very first startup issue as well.
I have "server side" mqtt client which I use to monitor and manage remote mqtt clients. I would like to extend this server module to keep tabs on the connectivity of the remote clients.
During normal operation, the remote clients regularly PING the broker, as per the broker logs:
1532924170: Received PINGREQ from c51
1532924170: Sending PINGRESP to c51
and when a disconnection occurs, the broker logs show this too:
1532924976: Client c51 has exceeded timeout, disconnecting.
1532924976: Socket error on client c51, disconnecting.
as well as the subsequent re-connection:
1532924978: New client connected from X.X.X.X as c51 (c1, k30).
1532924978: Sending CONNACK to c51 (0, 0)
I would like to monitor these 3 events from the mqtt-client held by the server module. Is this possible? If not, what alternative approach to "health" monitoring can you recommend?
No, you can not read these from a connected client.
The only pure MQTT approach is to make use of the Last Will and Testament (LWT) feature. You have the client set up a LWT publish a retained message to a client specific topic that marks it as offline. Then as the client connects it should publish a retained message to show you are online. If you disconnect cleanly (not triggered by keep alive time out you should manually publish the LWT message as the last thing before disconnecting).
It's also worth pointing out that ping messages only get sent if no other messages have been sent between the client and the broker in the keep alive period.
I have a voip app for ios, based on webrtc. I also have a signaling server made with nodejs. I can connect to the server and make calls without a problem. But tracking presence (online/offline) accurately is a problem.
Just for the record, here is a list of everything I did to ensure a stable connection:
Set the background mode "Voice over IP"
Flag the inputstream as a voip stream with "[inputStream setProperty:NSStreamNetworkServiceTypeVoIP
forKey:NSStreamNetworkServiceType];"
Turned on persistent wifi by setting "UIRequiresPersistentWiFi" to YES in the plist file
I implemented "setKeepAliveTimeout:handler:" and I use it to send a ping to the server (unnecessary, but you never know...)
I created a small test app that does nothing more than connect to the server and respond to "ping" with the message "pong". This app sends "ping" to the server when the keep alive timeout handler fires and the server replies with "pong". I also created a simple test server that does nothing more than let clients connect, send "ping" to a client when I send "send_ping" to it via telnet and responds to "ping" with the message "pong".
Here is my client code
What I expect is the following:
Starting the app and signing in should create a persistent connection to the server (works)
Telnetting into the server and typing send_ping makes the server send "ping" to the client and the client should send "pong" back (works)
Putting the device in standby should have no effect on the above ping-pong mechanism (doesn't work)
Putting the device in standby and unlocking it after a few hours, then sending a ping to it should make the client send a pong back (works)
Turning off wifi on the client (without cellular enabled) should be detected on the server-side and kill the socket (doesn't work)
I log all messages from the server in a textview on the client with a timestamp, and sometimes when I put the device in standby the pings I send from the server just don't arrive at all. Sometimes it takes over a minute for the app to receive the ping message, sometimes it responds immediately. I don't understand why it is so random. Sometimes this undesired behaviour starts after mere minutes in standby mode, sometimes it goes alright for a while but breaks after 20+ minutes, sometimes all messages from the server arrive at once as soon as I unlock the device.
Push notifications and voip push notifications could be a solution, but they are also slightly unreliable. There should be a way to make this work 100% of the time.
I am doing socket programming in Delphi 6 Pro using the ICS (TWSocket) library. I know my question may seem either convoluted or awkward, but let me explain my application needs so you understand why I want to do something that goes against the usual convention used with a listening socket, that of spinning off an incoming connection to a new socket returned by the Accept method and continue to listen for new connections on the currently set port.
In my application I accept connections from Skype for sending and receiving audio buffers involved with an active Skype call. The problem is that when Skype connects, there is no handshaking, identification, or authentication that would allow me to know what CALL ID the connection is for. Since Skype can conference calls together, there can be more than one active call at a time. However, I need to know which socket connections belong to which CALL ID.
Since the connection is a "blind" connection as stated above, the only way I can reliably map Skype socket connections to CALL IDs is by controlling carefully the port number I listen on. Then, when I tell Skype to connect the audio for a given CALL ID to a specific port number, I know that a connection coming in on that socket belongs to that Skype CALL ID. For example:
Find an available port number, iPortNumber.
Set my socket to listen on iPortNumber
Tell Skype to connect CALL ID iCallID to PORT number iPortNumber
When I get the SessionAvailable event, I know the incoming Skype connection is for CALL ID iCallID.
Rinse and repeat for each CALL ID I need to handle. I know this means I could end up chewing up a few extra ports but since the number of simultaneous Skype calls is always small I don't see that as a problem. What I am having difficulty with is the standard convention of having a Listening socket that spins off a new socket using Accept when a new connection comes in.
I want to Accept the connection on the Listening socket (same socket), and then specifically stop listening without having to close the connection since I don't want to accept any new connections on that port number anymore. Is there a way to do this?
An alternative avenue would be to use the newly created socket returned by Accept and then close the Listening socket, but then I have to come up with a more complicated method to track port numbers to Skype CALL IDs because, if I am correct in my knowledge, the newly created socket returned by Accept is connected on a different port number than the Listening socket so the Listening socket can keep listening on the existing port number. I'd like to avoid that extra complexity and hassle if I could.
If anyone has a better overall idea/paradigm on how to map my blind Skype connections to the Skype CALL IDs that are tied to them, please let me know. Also, I don't think it's possible, but if there's a clever way to get the process ID behind an incoming Socket connection from a process connecting on the same system as my app, I'd like to know.
One-time listening sockets are not that unusual. The FTP protocol uses them, for instance. Simply create a new listening socket on the desired port (or let the socket decide its own port that you can then retrieve), set its backlog to 1, then call accept() on it just once and close it. If accept() accepts a client connection, it returns a new socket handle that you use to communicate with that client. You don't need to keep the listening socket alive during that time.
I don't know what the ICS equivilent of that operation would be, but in Indy there is a TIdSimpleServer component for exactly this purpose (incidentally, Skype on Windows uses Indy).