NetTalk Central

Author Topic: Sessions, sockets, connections, timeout  (Read 2253 times)

jlavera

  • Newbie
  • *
  • Posts: 47
    • View Profile
    • Email
Sessions, sockets, connections, timeout
« on: March 18, 2021, 06:10:35 PM »
Hi,

I have a rest server, an app connects to it sending a request and obtaining an answer, and that's it. Each request includes the "login" information, more like a validation of the request.
I have the "Allow WebSockets" checkbox disabled, so I assume no sockets.
No cookies as well.
Also "Delete session on Logout" checked, although not sure what would be a "logout' or if there is one in this situation.
Session timeout is set to 1 second, but I'm not sure if I have "sessions" in this situation. Now here is my question; when the app connects and send the request, I guess it is opening a connection. The "duration" of this connection lasts until what? Until the app gets the answer? Until the Session timeout is done, or is it not related? Is there any reason why the connection would not close?

Kind regards,
Jorge Lavera

Jane

  • Sr. Member
  • ****
  • Posts: 357
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Sessions, sockets, connections, timeout
« Reply #1 on: March 18, 2021, 07:06:19 PM »
Hi, Jorge,

Logins, sessions, connections ..... 

Assuming that your service methods are grouped into a NetWebService, you can open the NetWebService properties and on the Security tab, mark the "Delete Session immediately" checkbox.

That checkbox also exists on each NetWebServiceMethod's Security tab, but they will inherit the setting from their parent service.

The client will not give up immediately.
For the client, from a command prompt you can type
      netstat -n
to get a list of active connections and their status.  Without the -n it will try to resolve the host names.

netstat -a will give a (much slower) list of active connections.

Google for a description of the various states: LISTENING, TIME_WAIT,CLOSE_WAIT,ESTABLISHED, etc.

Jane

jlavera

  • Newbie
  • *
  • Posts: 47
    • View Profile
    • Email
Re: Sessions, sockets, connections, timeout
« Reply #2 on: March 19, 2021, 02:41:41 AM »
Hi, Jane.

Thank you for your answer.
Yes, the server has methods grouped into a netwebservice.
I'm on Nettalk 11.43. I see the "Delete Session immediately" checkbox on the methods, and it IS ticked. I don't see this checkbox on the WebServer procedure, there is one 'Delete Session on Logout" (ticked) but no "Delete Session immediately".
The client are not browsers, but App in android or iOS phones, so I cannot execute the netstat stuff. You actually meant the client, or the server?

Kind regards,
Jorge Lavera

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11194
    • View Profile
Re: Sessions, sockets, connections, timeout
« Reply #3 on: March 19, 2021, 07:40:46 AM »
Hi Jorge,

>> Also "Delete session on Logout" checked, although not sure what would be a "logout' or if there is one in this situation.

since they are not logging in, or out, this setting is meaning less in this situation.

>> Now here is my question; when the app connects and send the request, I guess it is opening a connection. The "duration" of this connection lasts until what? Until the app gets the answer?

yes. In the reply the client is instructed to close the connection. Most do, but maybe some don't.
It's reasonably common for drive-by clients to not close the connection. (not that it means much).

<< Is there any reason why the connection would not close?

yes and no. So by default in the old version you are using the server side connection timeout is set to 0, although in later builds I've set that to a "big number" like 5 minutes.

But overall, in and of itself, "number of connections" is not a terribly exciting number.

Cheers
Bruce

jlavera

  • Newbie
  • *
  • Posts: 47
    • View Profile
    • Email
Re: Sessions, sockets, connections, timeout
« Reply #4 on: March 19, 2021, 10:17:29 AM »
"yes. In the reply the client is instructed to close the connection. Most do, but maybe some don't."

Can this cause problems in the server if we have a lot of users doing, say, over 200 calls per second?

<< Is there any reason why the connection would not close?
"yes and no. So by default in the old version you are using the server side connection timeout is set to 0, although in later builds I've set that to a "big number" like 5 minutes."

Is that the "Session Timeout" number set at the Advanced tab? It was setting by code to 90001 cents. of sec, or about 15 minutes, but I did tests of server heavy loading and caused problems (server collapsing), so I bring that down to about 1 second, where it looks like it works better. However, from time to time the server simply stops responding, although the program is still working. A processMonitor analisys show a lot of "connections" closing at that time, so we were wondering if it could be related.

Kind regards,
Jorge Lavera

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11194
    • View Profile
Re: Sessions, sockets, connections, timeout
« Reply #5 on: March 21, 2021, 09:55:27 PM »
Hi Jorge,

>> Is that the "Session Timeout" number set at the Advanced tab?

no, that is for the Session Timeout, not the Connection timeout.
The two have (quite literally) nothing to do with each other.

>>  It was setting by code to 90001 cents. of sec, or about 15 minutes, but I did tests of server heavy loading and caused problems (server collapsing),

The length of the session timeout should have very little impact on server work-load, so it would be interesting to duplicate the test you set up in this regard. I expect there is something else in play here - perhaps memory limits - but for API calls interaction with the session is minimal.

<< However, from time to time the server simply stops responding, although the program is still working.

This suggests that either

a) you are leaking threads, and hit the thread max (see log window to see if the thread being assigned to incoming requests is returning to 3 after quiet spells). or

b) you have a bug in your code which is causing the server to be "blocked" - usually the incorrect use of a critical section, or incorrect use of prop:sql, or something like that.

c) You are using a SQL database and the clarion Exe is losing the connection to the database.

>> A processMonitor analisys show a lot of "connections" closing at that time, so we were wondering if it could be related.

Incoming connections will close, so if they are not being responded to you will see them closing.

Also - on the "Performance" tab there is a whole slew of numbers that gives you cluess as to what might be high when the program stops responding. Perhaps take a look at that?


cheers
Bruce