It's not an error, it's an inquiry about PING messages #2
Comments
|
Hi @ferorted, thank you for your kind words! I've created new branch named |
|
Hi @alim-zanibekov, Ping every 1 min: However, in many test I get the following error: INFO: 2024/06/28 20:00:16 [IP:port]: imei conected: 865648061643078 I reboot again the device. It stills on the table (but Moving status) with fix GPS and good GSM signal: INFO: 2024/06/28 20:12:50 [IP:port]: imei conected: 865648061643078 I reboot again the device. It stills on the table (but Moving status) with fix GPS and good GSM signal: INFO: 2024/06/28 20:12:50 [IP:port]: imei connected: 865648061643078 Please, pay attention at 2 last lines: received ping, while device is disconnected and not reconnected. Client list does not showthe IMEI as connected. Thank you very much. |
|
Hi @ferorted,
I don't see any log message that could create this line. Did you change anything related to the connection handling/closing logic? I rechecked the code and do not see a situation where, after an exception, the server continues to receive messages from the client. I noticed that you are running this on Windows (wsarecv), I'm not very familiar with the Windows TCP stack so I can't tell if this disconnect might be caused by some default settings related to win TCP socket keepalive timeouts, or some kind of NAT. Either way I would try to reduce the ping timeout to about 60-90s. There is another possibility for this exception. Perhaps we should respond to PING messages, but I still can't find any information about this. Anyway, I created a new branch |
|
Hi @alim-zanibekov, thank you so much for your interest, So, I did few new tests with your new code (running on windows, with no modifications on your code) and it seems works fine (only a weir count in client-list, please see below). Settings: INFO: 2024/07/01 17:23:54 http server listening at 0.0.0.0:18081 It seems OK. but if another device is connected while first device is still connected: INFO: 2024/07/01 18:48:13 [354017118805713-127.0.0.1:50554]: message: 000000000000002b08010000016b40d9ad80010f0ea850209a69000094000012000000030147030109007301f10000601a000100003240 Then, client-list only shows one connected device : StatusCode : 200 Headers : {[Content-Length, 553], [Content-Type, application/octet-stream], [Date, Mon, 01 Jul 2024 16:51:12 GMT]} Disconnected due timeout: Now, client-list shows only one, but different RawContentLength: StatusCode : 200 Headers : {[Content-Length, 278], [Content-Type, application/octet-stream], [Date, Mon, 01 Jul 2024 16:58:37 GMT]} I will continue conducted more tests and let you know. |
|
Hi @ferorted, thank you for your feedback
I forgot to trim the imei reading buffer imei = strings.TrimSpace(string(buf)) // here
imei = strings.TrimSpace(string(buf[:imeiLen])) // like thisI fixed this problem (also now list-clients returns json instead of binary) and merged the latest changes from |
|
Hi again @alim-zanibekov, I'm just testing to check that the device can stay connected to the server for very long periods of time without sending data, but sending PING every 30 min. to avoid connection will be closed by GSM provider. Then, I want to check when device loses GSM coverage and its connection, the server can detect it, and when the device has GSM coverage again, it reconnects and the server sees it. In order not to fill this post, I attach the traces in the attached document traces.txt, of a long test. It was done with version prior your last changes about list-clients, and with following settings: on it, you can see the following points:
Could it be that the connect/disconnect events are being handled or only be printed incorrectly? Please note that there have been some connection attempts from something or someone other than a Teltonika device, and they have apparently been handled well, at 23:25:00, 1:07:52, 1:51:32, 4:13:00, 7:13:16, 10:20:20 and 10:41:13 Best regards, |
|
Now, I'm going to repeat the same test with the latest version of your code |
|
Hi @ferorted,
This is hardly possible over the Internet (only on local networks), it is better to set a reasonable ping around a couple of minutes and forget about this problem, it's only 1 byte
I made a fix, but I don't know if my fix will help
I understood what is the problem with multiple connections, it happens because sometimes the server may not know that the connection was closed from the client side and the client connects again, here the example from your logs: I've created a fix for this problem that simply closes the previous connection. (already pushed)
These are 2 different clients 62.32.248.54:5086 and 62.32.186.243:5551, the fix for 2 should help Hope this helps |
|
Hi @alim-zanibekov and thank you dor your info. I'm afraid this error still happen on your last code version: Setings: INFO: 2024/07/03 12:48:19 [145.1.189.63:8632]: connected About "Many times a PING arrives while being Disconnected," in this first test no PING was received while client disconnected. It looks fine. Thank you again |
|
Hi @ferorted, could you try removing all SetReadDeadline and SetWriteDeadline calls and see what happens? |
|
Hi, updateReadDeadline := func() bool { It is very strange, so I will do some tests to make sure that the problem is not with the Teltonika device. |
|
Hi @ferorted, as I see connection drops within a couple of minutes since the last ping message, maybe something wrong with the sleep, open link timeout, or response timeout settings link1, link2 Can you also try adding a pong message and see if it breaks the connection or is processed normally Something like this if peek[0] == 0xFF { // ping packet
if _, err = reader.Discard(1); err != nil {
logger.Error.Printf("[%s]: reader discard error (%v)", logKey, err)
return
}
logger.Info.Printf("[%s]: received ping", logKey)
+ if writeWithDeadline([]byte{0xFF}) {
+ logger.Info.Printf("[%s]: sent pong", logKey)
+ }
continue
} |
|
Thank you very much for your great interest in helping me. |
|
Hi @alim-zanibekov, INFO: 2024/07/08 12:39:04 [865648061643078-90.75.99.129:31186]: io elements [frame #0]: Ignition: true, Movement: true, Digital Input 1: false, External Voltage: 12.733V, Battery Voltage: 4.093V, Analog Input 1: 0.043V I'm still waiting for Teltonika's reply. I'll keep you posted. |
|
Hi @ferorted, thanks for the tests! So we know that your device is handling ping messages correctly, we can try adding pings on the server side and even try to turn off pings from the tracker side. This may work better in your case if the problem is in the tracker logic. However, are there such problems with connection drops with 2-3 minutes pings? Are you sure it's not a network problem? |
|
Hi @alim-zanibekov, Apparently, it is not a problem with the PING time interval, the socket simply closes every 60 min. and I still don't know if it is a problem with the device or the network. |
|
Hi @alim-zanibekov,, I will continue testing and will inform you if I discover anything else. Thank you |
|
Hi @alim-zanibekov, |
Dear Sir,
I've been testing your simple-tcp-server, which I find to be a fantastic piece of work. However, it appears not to handle PING messages (0xFF) sent by Teltonika devices. This causes an error and subsequent closure of the connection with the device if a normal data message arrives after a PING.
I would greatly appreciate it if you could provide me with some guidance on how to filter received PING messages. I've tried various methods after readBuffer in handleConnection, but haven't been successful.
Thank you.
The text was updated successfully, but these errors were encountered: