I was wondering If I need to wait for a response from the server that a command was executed before executing another command or if the BLE stack takes care of this under the hood so to speak.
For example, I want to write to a characteristic and then read from it. Should I execute these commands in tandem or should I wait for the onWriteRequest callback method to fire before I send a read request?
If yes to former question, how many resend attempts will the BLE stack make, and how long does it wait for a response before resending a packet?
With the GATT protocol you can only have one outstanding operation at a time. You must wait for a response until you can send the next request. For Android you therefore have to wait for the onCharacteristicWrite until you can send, for example, a read request. I guess it's the same on iOS.
The Bluetooth stack sends the request packet to the Bluetooth controller in the phone. The Bluetooth controller which implements the link layer will then send the packet at the next opportunity (connection event). If the packet is not acknowledged it will resend the same packet until acknowledged or the link times out (supervision timeout). The default timeout is 5 seconds (it was 20 seconds in earlier Android versions). The peripheral can however change the timeout value by issuing a Connection Parameter Update Request.
Related
As we know the messages in buffer shall be still sent out even after socket closed. this is usefull, but there's a use case that we want to wait the messages is sent and acked by peer,
e.g. in embeded device, a firmware upgrade function in web ui. after upgrade done a message is sent to web ui then reboot the device. we want the message is sent and acked, or reboot may drop messages. then web ui lost reply.
so, is there a way in linux wait a socket (closed or not closed) sent out and acked all messages ?
I want to code a synchronous programs in which cloud send mqtt message to device, then using simple to wait response to judge whether is successed. but it need a timeout, such as 5 seconds, app think it's failed. The keepalive parameter of mqtt simple API seems to lose efficacy, but the big probability is that I use or understand the error.
I would very appreciate it if you guys can suggest me some advice
print("----before simple")
msg = subscribe.simple("paho/test/simple", hostname="39.100.79.76",port=1883,keepalive=5,will = {'topic': "paho/test/disconnect", 'payload':"network or device anomaly", 'qos':2, 'retain':0})
print("----after simple")
then run it, simple API cannot to end
----before simple
infinite...
Correctly determine if it is successful to synchronize the edge cloud application
You have miss understood what the keepalive property for a MQTT client is for.
The keepalive is used by the Broker to check if the client is still functioning. It does this by keeping a timer since the last MQTT packet was received from the client. If it does not receive a packet when the timer reaches the keepalive time it sends a MQTT Ping request to the client. If it doesn't receive a response to that packet with in half the keepalive time then is will disconnect the client and publish any Last Will & Testament message that the client may have set.
The Paho client library handles MQTT Ping messages in the background with no need for the user to be involved.
The code sample you have provided will wait indefinitely for a response.
My HTTP server needs to make sure that HTTP responses are delivered to the client.
I feel (and I will implement it so) that the most correctly way is to send the "I received the data" request from the client.
But I have a bit academic question:
Has the server some other means to detect whether the response delivered to the client or not (say due to the client's computer was evaporated by a direct hit of an H-bomb during data transmission)?
According to the node.js http documentation:
Class: http.ServerResponse
...
Event: 'finish'
Emitted when the response has been sent. More specifically, this event
is emitted when the last segment of the response headers and body have
been handed off to the operating system for transmission over the
network. It does not imply that the client has received anything yet.
After this event, no more events will be emitted on the response
object.
Also I did not find nothing better in the 'net' module documentation.
So it seems I can only know that my data is in the kernel buffer for transmisstion over the network.
Can I detect some errors at this transmission by Node.js means?
Can I detect some errors at this transmission by some easy-to-implement non-Node.js means?
Any links and thoughts that this is not an HTTP way or even not a TCP way are also appreciated.
The thing about TCP is that the receiver must acknowledge the fact that it receives every single bit of data. If that's not the case, sender keeps sending the pieces of data that receiver has not yet acknowledged to receive.
I checked out the Net module and I saw this interesting piece:
Event: 'end'
#
Added in: v0.1.90
Emitted when the other end of the socket sends a FIN packet.
I have no implementation idea for this but still, this might be useful for your case.
In the Bluetooth 4.0-4.2 Specifications Vol 3 Part F, I can find this text:
Commands and notifications that are received but cannot be processed, due to
buffer overflows or other reasons, shall be discarded. Therefore, those PDUs
must be considered to be unreliable.
I wonder, who receives? For Write Commands, is it the ATT server that receives from the ATT client, or might it also be the ATT layer of the sender host that receives a request to send a Write Command from the client app that drops the Write Command, i.e. it gets dropped before even being sent out over the air?
The air interface is often limited in the number of packets it can buffer for a Connection Event. Ditto Notification vs Indication in the other direction (server to client)
"Commands and notifications that are received..."
Commands, for example, Write request that is from Client to Server, so the Server is receiver. The process is that the client send out the write request to server, and when the server receive the write request(lower layer first received) but it find there is no buffer(or other reasons) for this write request and it will discard the write request(higher layer will not receive the write request).
Notifications, instead, from Server to Client, so the Client is receiver. When the client receive the notification but there is no buffer(or other reasons) it will discard the notification.
This is about flow control of communication protocols not just only for Bluetooth. So if you understand flow control you may not have such confusion.
I wonder, who receives? For Write Commands, is it the ATT server that receives from the ATT client,
Yes, it is the ATT server. Both ATT and GATT are not reliable. however the link layer is reliable. I assume the higher layer e.g. the application shall constitute reliability checking.
or might it also be the ATT layer of the sender host that receives a
request to send a Write Command from the client app that drops the
Write Command, i.e. it gets dropped before even being sent out over
the air?
This is out of spec,I think Bluetooth stack should return corresponding error e.g. "failer" due to no memory.
I have minimum 3 TCP client, each has a Thread. I'm sending out messages and waiting for the answer, but sometimes I have to wait to receive the response from all client, this is depending what kind of message sent the server out. I already made to send messages to the clients and receiving, but when I have to wait for the other client response I couldn't do that until now.
As far as you didn't mention your environment/language, I assume C#/.NET 4
You need a mechanism for each client to signal the arrival of a response. This is usually done with AutoResetEvents: Each client sends his response back to the server. The server itself can extract from the reponse (or any other property, e.g. the connection) with client has sent it. Then he sets the apporpriate AutoResetEvent.
The thread that formerly initiated sending the message can afterwards wait for all AutoResetEvents to be set.