I run a KaaClient on intel edison with temperature sensor, and updating the temperature onto KaaServer, but sometimes when I start or resume the client, it will hang on
RecordInfo recordInfo = future.get();
After investigating log, I was wondering if it is becuase that I sent the information to server[2] between those logs[1][3]:
[1] [pool-68-thread-1]INFO o.k.k.c.c.i.DefaultOperationDataProcessor - Created Sync request: {"requestId": 1, "syncRequestMetaData": ,...
[2] [Thread-47] INFO c.i.i.k.e.k.KaaModbusComponent-[readTemperature] sent log record to server
[3] [pool-68-thread-1] INFO o.k.k.c.c.i.c.DefaultOperationTcpChannel - ConnAck (ACCEPTED) message received for channel [default_operation_tcp_channel]
...
In the above sequence, [1][2][3], it will always hang on future.get();
In other sequences, such as [2][1][3] or [1][3][2], it works.
Could some expert help if it is caused by this? if yes, please help guide me what's the good way to resolve this. thanks.
Related
I'm trying to create a server that sets up a Unix socket and listens for clients which send/receive data. I've made a small repository to recreate the problem.
The server runs and it can receive data from the clients that connect, but I can't get the server response to be read from the client without an error on the server.
I have commented out the offending code on the client and server. Uncomment both to recreate the problem.
When the code to respond to the client is uncommented, I get this error on the server:
thread '' panicked at 'called Result::unwrap() on an Err value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', src/main.rs:77:42
MRE Link
Your code calls set_read_timeout to set the timeout on the socket. Its documentation states that on Unix it results in a WouldBlock error in case of timeout, which is precisely what happens to you.
As to why your client times out, the likely reason is that the server calls stream.read_to_string(&mut response), which reads the stream until end-of-file. On the other hand, your client calls write_all() followed by flush(), and (after uncommenting the offending code) attempts to read the response. But the attempt to read the response means that the stream is not closed, so the server will wait for EOF, and you have a deadlock on your hands. Note that none of this is specific to Rust; you would have the exact same issue in C++ or Python.
To fix the issue, you need to use a protocol in your communication. A very simple protocol could consist of first sending the message size (in a fixed format, perhaps 4 bytes in length) and only then the actual message. The code that reads from the stream would do the same: first read the message size and then the message itself. Even better than inventing your own protocol would be to use an existing one, e.g. to exchange messages using serde.
I am not able to received complete responses from my BLE device which I am supposed to receive for the commands written to characteristics using flutter_blue. What I am receiving in response is the command itself which I sent for write. The responses received are being decoded properly.
The commands which I'm trying to write are OBDII protocols which are
AT Z
AT H0
AT H0
AT L0
AT S0
01 0C
Surprisingly the command "AT Z" gives response "ELM 327v1.5" which is correct. This is the only command from which I am receiving the correct response. All other commands are returning the command itself which is partially correct because most of the times the actual responses are received along with the command name.
The response reading and decoding is implemented in the following way
await read_CX.setNotifyValue(true);
read_CX.value.listen((response) {
print(utf8.decode(response));
}
Has anyone faced similar issue of receiving incomplete data? Can anyone please help me out?
Thanks!!
First, add ATE0\r to your init sequence, this will stop the adapter from echoing back what you send.
Then, familiarize yourself with the AT commands provided by the ELM327, e.g. by reading https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf.
I am newbie on Fix in general and I have started from QuickFix to make practice. I apology in advance from the following trivial questions.
I have understood that to handle ExecutionReport I need to use crack() method inside FromApp() and implementing OnMessage().
But what I have two questions :
1) What happens if during a Partially fill order ExecutionReport message suddenly session drops, which is the way to handle this situation. Trying to reconnect and Send a request ? Please Can you provide a simple explanation in steps and what QuickFix Api method should I use ?
2) If I need to implement a FixEngine to handle dropcopy should I be aware of something in particular ?
Thank you for your help
1). Just make sure ResetOnDisconnect parameter is set to N for your trading session: ResetOnDisconnect=N (docs)
QuickFix will be automatically attempting to reconnect every ReconnectInterval seconds;
Once connected (with ResetOnDisconnect=N) it will also automatically exchange last known message sequence numbers with the FIX server, and the ones lost during the disconnection will be re-sent - so without a line of code you will receive the missing messages.
Also, if disconnection was for a longer period of time, you may want to send Order Status Request (H) message to the FIX server to receive actual ExecutionReport for your pending orders.
2) The question is too general for me to answer...
I want to create offline multiplayer game for android, so I need reliable p2p communication between devices. Google nearby connections work quite ok, but I found one issue. Setup is standard - device A advertises, device D discovers and connects to A. Then D disconnects, discovers again and connects again. After one to ten iterations D can still connect to A and receive data from A, but it can no longer send data. I call sendPayload with Payload.fromBytes, I receive onSuccessCallback, but A does not receive this payload. Later on D receives onPayloadTransferUpdate with status code 2. Further reconnects does not solve the problem. Only thing that solves the problem reliably is reboot.
Some logs:
03-21 12:20:25.827 30317-30317/com.alienff.ntest I/Log: [21.03.2018 12:20:25.827] [main] MainActivity: sending payload -5864147190526311071
03-21 12:20:25.841 30317-30317/com.alienff.ntest I/Log: [21.03.2018 12:20:25.841] [main] MainActivity: payload cent
...
03-21 12:21:16.925 3066-3215/? D/WifiStateMachine: Current network is: "___mm___" , ID is: 0
03-21 12:21:16.926 3066-3215/? D/WifiStateMachine: Current network is still qualified due to heavy traffic, txSuccessRate=2.1973258256066233 rxSuccessRate=0.0
03-21 12:21:16.926 3066-3215/? D/WifiStateMachine: Current network is 5GHz, bail out...
03-21 12:21:17.408 4049-4049/? D/io_stats: !# 179,0 r 906136 23065676 w 370340 7270584 d 46705 2438912 f 147311 147270 iot 680350 657112 th 51200 0 0 pt 0 inp 0 0 55938.769
03-21 12:21:17.571 10176-30596/? W/NearbyConnections: Unexpected call to physicalConnectionClosed() for medium WIFI_LAN while NearbyRecorder has active medium BLUETOOTH -- metadata{ service_id: 0 }
03-21 12:21:17.576 10176-30596/? W/NearbyConnections: Unexpected call to physicalConnectionClosed() for medium WIFI_LAN with no corresponding EstablishedConnection that was previously opened. -- metadata{ service_id: 0 }
03-21 12:21:17.579 10176-30596/? W/NearbyConnections: NearbyRecorder expected no more active physical connections before logging this endpoint connection. -- metadata{ service_id: 0 }
03-21 12:21:17.585 3336-3929/? E/BluetoothRemoteDevices: setRfcommConnected false
03-21 12:21:17.586 30317-30317/com.alienff.ntest I/Log: [21.03.2018 12:21:17.586] [main] MainActivity: onPayloadTransferUpdate. endpointId: 7oRz payloadId: -5864147190526311071 bytesTransferred: 0 status: 2
03-21 12:21:17.597 30317-30317/com.alienff.ntest I/Log: [21.03.2018 12:21:17.596] [main] MainActivity: onDisconnected: 7oRz
Do you know how to make google nearby connections reconnect reliably?
Thank you!
I haven't seen this before, so I'm going to have you do some debugging for me.
Give me the model names of all the devices you can reproduce this on.
Tell me what type of Payload (BYTE, FILE, STREAM) you're sending.
Reproduce this bug while running logcat. Look for the log tags "NearbyConnections" and "NearbyMediums". Let me know if you see any errors/warnings.
Reproduce this bug, and then force kill your app. Wait 45 seconds. You should see Wifi/Bluetooth toggle off/on. Reopen the app and try to reproduce again.
Current thoughts:
Status Code 2 is "PayloadTransferUpdate.Status.FAILURE". Usually that's immediately followed by a disconnection because the socket is assumed broken. However, it doesn't look like the socket has gone bad. You're still receiving data and, internally, we send a flurry of control messages over the socket when connecting and those are all going through successfully or you wouldn't get onConnectionResult. That means something is going wrong with the Payload itself; either on your side, or ours. I suspect you're sending either FILE or STREAM payloads because I don't know of a way that BYTE payloads can fail. FILE payloads can fail if the file has moved or the ParcelFileDescriptor becomes invalid. STREAM payloads can fail if the socket/ParceFileDescriptor are closed or garbage collected.
Disclaimer: I work on Nearby Connections
I am trying to set a timeout on write operations when using GCDAsyncSocket. The code is pretty simple and is the following.
[iAsyncSocket writeData:bytesToSend withTimeout:3.0 tag:0];
Then I disable the Internet connection on my Mac and wait for write timeout to occur, but nothing happens. I don't get a disconnection with a GCDAsyncSocketWriteTimeoutError error as I should.
I have also validated that my server stops, as expected, receiving the messages after I turn off the Internet connection.
I have looked inside the source code and I have found out that the writeTimer, that is responsible for firing a write timeout event, is always cancelled (function endCurrentWrite is called). Tracing back to where the timer is cancelled, I ended up at the following line of code.
ssize_t result = write(socketFD, buffer, (size_t)bytesToWrite);
The write system call always returns the total number of bytes that I am sending, as if the socket manages to send the data although there is no Internet connection. Is this logical?
Has anyone come up with the same problem or seen similar behaviour? Or has anyone managed to set a write timeout for a GCDAsyncSocket?
Thanks a lot.