Anyone (big) using New ServerNet Network Layer?

I’ve tried going to the new “ServerNet” network layer a couple times: and each time I ended up reverting because of various issues: mainly - it was slow for big databases (100 users+).

I’m seeing more new commands (such as “ABORT PROCESS BY ID”) that only work with ServerNet.

Does anyone out there have a DB of 100+ users that’s using ServerNet network layer?

We have a 200+ users database configuration. Interpreted mode.

Server Windows 2012, clients Windows 10 + RDS Windows 2012 (we are only using 4D 32 bits clients side because of 4Dwrite).

We met the same issue as you with the new network layer (v15->v16) until we switched to the v17 (v17.2).

We turned on the new network layer few weeks ago and we have got no trouble so far.

This will let us using the SSO feature and some new commands

Hope this help.

Vincent

Thanks Vincent, that’s helpful to know.

I’ll begin to transition some clients to ServerNet, and monitor them.

Last time we tried it was versoin 17.0 HF3 - it ran great until we hit about 450 users.

We have a plan to debug this with 4D, but for now we’re running fine on the legacy network layer. What other commands besides ABORT PROCESS BY ID require ServerNet?

What other commands besides ABORT PROCESS BY ID require ServerNet?

I’m not sure about the list of commands, however one important one to know is: preemptive tasks on client side: this feature is only available if you are using the new network layer.

Hi Tony,

I was wondering if you had the issue again, maybe solved this or have more intel?

Our company activated the new network layer (NNL) in our 4D v17 enviroments, 2 weeks ago by default. Mainly because this is the new standard an because of issues in the legacy layer (we have alot of strange SQL, null point errors in legacy).

Honestly last time we activated the NNL was years ago in v15R versions and early v16. I sometimes still have a nightmare from the issue when more than 32 clients would connect and the perfomance dropped to a dead stop and no one else could connect. After 15 years I have alot more nightmares ofcourse not always 4D fault. :mrgreen:

Our online products consist of five hosted 4D 17.3hf1 Servers, 1000+ unique users (web and desktop). All running on windows server 2016 and the desktops Windows 2016 RDS.

Today on one our 4D Servers (the biggest of the five, 130 GB datafile with 500 MB structure) Around 90-100 4D clients connections, the clients became extremely slow. Alot of users got disconnected. No users could connect to the server. We closed 4D server normally en started it normally and the issue was gone.

Last week I already reverted back our biggest On-Premise customer (daily 136, 4d clients) back to legacy after one day! They have alot of migrating users switching from networks the whole day (ofcourse not logging out the system when they unplug). So in the old legacy they would simply crash the connection but in the NNL they pile up as sleeping users wich no one can drop and taking up free 4D licenses (I had 8 users in one day). Combined with a bug on our side that we prevent the same user from connecting again when registred made it impossible on that site.

greetings,

Yuri

Yuri,

I’ve turned ServerNet back on for a swath of my databases: about 100 smaller databases: and there’s been no problems recently. However, the busiest of those databases is perhaps a 40 concurrent user system. (only about 15 of them are more than 10 users) I haven’t had any issues with these systems.

It also seems that perhaps since 17r6 (all my databases are on 17r6) that there have been improvements: Perhaps this is because my clients are now 64-bit: which I think has been a HUGE stability improvement.

Regards,
Tony

I have the same experience. ServerNet seems to be working pretty good for our server with 80+ users and 500 processes. Currently running 17.3 HF2. 64 bit on both server and clients seems to be a good solution. However we used to have problems with the server running a Windows 2008 R2 and the basic 17.3. All client connections suddenly dropped and no client could log in to the server. The server seemed to be working. All stored procedures were up and running. It was however impossible to quit to restart the server so it had to be force quit but with no data corruption occurring. This happened approximately once a week. Since then we have moved the production database to a windows 2016 installation and at the same time installed 17.3 hf2. Knock on wood. We have not seen this type of server crashes since the move and upgrade. Have anyone else seen these problems?

: Johan BRAUN

However we used to have problems with the server running a Windows
2008 R2

We have seen many of these issues with Server 2003, some with 2008 and less with 2008 R2. None with 2012.

As more users you have, as more processes you usually have.
As long as your users connect one after one and each user opens only a small set of processes and uses all of them (none get postponed), all works fine, even with 2003.

But if many users connect at the same time (or open new windows), many new Windows sockets are opened in a short time window - and that could be seen as attack.

Search for “Sync attack”. You will find much more issues for older servers as for new ones.
Example: https://social.technet.microsoft.com/Forums/Lync/en-US/c53806fa-3c62-4b2b-a85a-fb1047a231bd/sync-attack-protection?forum=winserversecurity

Some years ago I suggested to play with registry and all this settings, as soon you found the good one it should help.
These days I recommend to go to windows Server 2016 or 2019…

Oh hello again. Sorry for hijacking this tread. So we went for a brand new installation of the windows 2016 server and we thought that the “frozen database connections” were gone. But no. We have had 2 connection freeze ups in the last 2 weeks. It does not seem to have any correlation with db up time or specific times.

We are currently using 4D 17.3 HF2 on server and clients.

But this time i made a few other observations:

  • The number of reported connected users were fixed. No user could however use the application.

  • No one could log on. Trying to log on did not produce an error directly. It took the client several minutes to time out and report an error. (Unimplemented error)

  • For those who force quit their clients the number of users were not decreasing BUT the number of used licenses were decreasing. (So there were some communication between the client and server)

  • After force quitting all sessions to the server we saw that the number of used licenses were dropped to zero. Then the list of users dropped to zero.

  • There were still not possible to create a client connection to the server so we restared the server

  • The server shut down without any crash and we restarted. Production back to normal.

  • The event logs on the server does not show up any suspicious errors or events preceding this episode.

Thomas please advice. What are the next steps?

this is a special issue, needing further detailed investigation.
Please open a TAOW case.