Ambiguos gate client disconnection

[D.Tkalcec (RTC)]

There was a bug in RTC SDK v7.32 and v7.33 which made the TRtcGateway component unusable with a single-threaded Server.
Please, download the latest update (RTC SDK v7.34 - just released) and let me know if it solves your problem as well.

Also, to make sure that Anti-Virus software isn't causing your problems, unless you have the option to entirely disable the Anti-Virus software and see if that fixes your issue, you should set StreamBlockSizeOut:=6 and StreamBlockSizeIn:=6 on the GateCli:TRtcHttpGateClient component to at least avoid problems caused by the Anti-Virus software buffering requests and/or responses for too long.

Best Regards,
Danijel Tkalcec

[ISIGest]

Sorry but nothing to do.
It always disconnect after about 80seconds.

[D.Tkalcec (RTC)]

Than you for your feedback.

I've found and fixed more bugs related to the way StreamBlockSizeIn and StreamBlockSizeOut properties were implemented, which resulted in premature disconnects and/or flooding in my tests. Please, download RTC SDK v7.35 (released now) and let me know if this fixes your problems.

Make sure to set StreamBlockSizeIn:=1 and StreamBlockSizeOut:=1 on the TRtcHttpGateClient component used by the problematic Gate Client, to avoid issues with Anti-Virus software buffering requests/responses or closing an idle connection after 30 seconds.

Should you still experience disconnect issues when sending large amounts of data, use the new functions "SetupLowestReceivingSpeed" and "SetupLowestSendingSpeed" on the Gateway and on Gate Clients to configure the lowest speed available to each connection. This tells the RTC SDK to use smaller input and/or output buffers to minimize problems of dropped TCP/IP packets, which can also results in disconnects. Receiving and Sending speed is configured per connection and should be done on both sides (Gateway and Gate Client).

Check the "Updates_Latest.txt" file for more info.

Best Regards,
Danijel Tkalcec

[ISIGest]

For now I've recompiled only the server with 735 and now that client work perfect after 10minutes...
I've found now other 3 clients that sometimes gone down.
Tomorrow I recompile and release the client and test it.
I will keep the situation under control and let you know if there was any news.

Thank you so much.

Regards

[D.Tkalcec (RTC)]

Thanks again for your feedback.

I've been running a number of tests inside LAN and over the Internet in the last 24 hours and did not experience any more unexplained disconnects with Gateway and Gate Client components after fixing StreamBlockSizeIn and StreamBlockSizeOut properties, but ... if you do find any more issues, please let me know.

PS. I've released RTC SDK 7.36 now as the next stable quarterly update. Compared to v7.35 which you are using now, there were only a few minor changes, but I would still recommend updating - just to stay on the safe side.

Best Regards,
Danijel Tkalcec

[ISIGest]

Now in Debug when I start the Gate I got an exception 'NOT Found @205(InternalResetOutput)'...what is this?

[D.Tkalcec (RTC)]

That is normal and expected.

It means that you have restarted the Gateway without closing Gate Clients, which is fine, but unless the Gateway was unavailable for several minutes and Gate Clients have logged out,  these Gate Clients will try to relogin with their old UserID, which can not work for obviois reasons.

The Gateway will then raise an internal exception and respond to the Gate Client that the UserID was not found, after which the Gate Client will log out and log in with a request to receive a new UserID.

By the way ...

If you pause the Gateway process while debugging for several seconds, Gate Clients will start closing their connections because of a missing PING from the Gateway. If you need to debug your own Gateway code, make sure to add Gateway exceptions to the ignore list, so they do not pause the Gateway. Also make sure to be quick when the process is paused inside your code, or take into account that Gate Clients will start logging out while you are looking at the code.

To debug the Gateway code or your own code used inside the Gateway, it is better to log what the gateway is doing instrad of using the debugger. Only use the debugger when you have identified a problem and know exactly where you have to place a breakpoint.

Best Regards,
Danijel Tkalcec

[Pieter]

Hi Danijel,

I'm having the same type of issue when trying to connect to a gateway via a hardware firewall, even though this firewall is currently set to allow all traffic. The client connects to the HttpServer without problems but the UserAuth and UserInfo are not received on the gateway. When I test without the firewall everything works fine...

- I have installed version 7.3.6
- The StreamBlockSizeIn/Out are set to 1
- The GatePrimaryKeys match
- The HttpServer is multithreaded
- All Timeout values on the server are set to -1

Do you have any idea what might be causing this?

Best regards,
Pieter

[D.Tkalcec (RTC)]

Compile your Gateway Project with RTC_DEBUG and DEBUG_RTCGATE compiler defines declared in Project options, make sure there are no files in the LOG sub-folder where you place the Gateway exe before starting the Gateway, leave the Gateway running until that problematic Client tries to log in, then stop the Gateway and wait for all connections to close, then close the Gateway process.

There should now be a LOG folder with several files with the log extension. Please, send me all the files from the LOG folder (ZIP compressed) by EMail to:


Best Regards,
Danijel Tkalcec

[Pieter]

Hi Danijel,

I have added the compiler defines to both the server and the client project options and performed a rebuild.
When I run them they produce only one log file each: Server.exe.DEBUG.log and Client.exe.DEBUG.log.

I wonder if this is correct since you said that several log files should be produced.
In the log files I don't see any specific reference to gateway communication.

Just so you know, I'm compiling with Delphi 10.1 Berlin 64 bit.

Best regards,
Pieter

[D.Tkalcec (RTC)]

My mistake. The 2nd compiler define for the Gateway is RTCGATE_DEBUG and not DEBUG_RTCGATE.

I also need to know the full URI and HTTP headers received on the Gateway from that problematic Client. See my replies to ISIGest (above) for details.

Best Regards,
Danijel Tkalcec

[Pieter]

Thank you. I will send you the debug logs and header information.

Best regards,
Pieter

[Pieter]

Hi Danijel,

I was just wondering, did you receive the log files in good order?

Thank you and best regards,
Pieter

[D.Tkalcec (RTC)]

We have been moving to a new appartment since last thursday and I did not have time to check my E-Mails yet. I will check later today or tomorrow and get back to you then.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

Thanks again for reporting this issue and for sending me the LOG files.

After spending the last 4 hours staring at the log files you've sent me and checking the Gateway Login procedure over-and-over-again, wondering how that could be possible, it finally hit me. I forgot to check "if Sender.Request.Complete" in the Login data providers OnDataReceived event before reading the request content body and processing user login.

Everything was working fine if "GateUserInfo" and "GateUserAuth" properties were empty on the Gate Client, or if the complete Login request was received before the 1st call to Login data provider's OnDataReceived event, but ... if the request was received in more than one TCP/IP packet and the OnDataReceived event was called more than once for the same Login request, the Login procedure would be executed more than once for the same Client, creating a new User ID with each call and triggering the BeforeUserLogin event with a new UserID and empty "UserLogin" and "UserInfo" parameters for each call.

Anyway ... this bug should be fixed in the latest RTC SDK update (v7.38 - just released).
Please download it, try it out and let me know if everything works now.

PS. You only need to rebuild and restart the Gateway/Server.

Best Regards,
Danijel Tkalcec