Need help with fphttpserver locking up

[Thaddy]

1000 is about correct, the limit on Windows is around 4096.
But indeed, it is simply the amount of concurrent connections that caused this.

[LeP]

1000 is about correct, the limit on Windows is around 4096.
But indeed, it is simply the amount of concurrent connections that caused this.

@Thaddy, the limits are "legals" for EULA with Microsoft (Windows workstation), but not "physics" ... I mean that you can have how many connections you need  for internal scope like "sync". I tried with two Win11 Pro (last version, last update) and I can acts 50 connections concurently without any issues.

See section [2d] of the pdf linked.

Ref: https://www.microsoft.com/content/dam/microsoft/usetm/documents/windows/11/oem-(pre-installed)/UseTerms_OEM_Windows_11_English.pdf

Of course, those legal terms limit the functions of a normal workstation, but I think there are too much to speak about, and this is not the rigth place.

[rvk]

Actually... the problem here is that fplisten uses 5 as default for backlog connections.
The limit (maximum) for this value can be 65535. (it's the limit for concurrent connection on a tcp port)

https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen

TFPHTTServer uses a QueueSize of 5. It calls fplisten with that 5 as queue of pending connections (backlog).

Code: Pascal  [Select][+][-]

1. function fplisten      (s:cint; backlog : cint):cint;
2. begin
3.   fplisten:={$IFDEF FPC_DOTTEDUNITS}WinApi.{$ENDIF}Winsock2.Listen(S,backlog);
4. end;

The maximum length of the queue of pending connections. If set to SOMAXCONN, the underlying service provider responsible for socket s will set the backlog to a maximum reasonable value. If set to SOMAXCONN_HINT(N) (where N is a number), the backlog value will be N, adjusted to be within the range (200, 65535). Note that SOMAXCONN_HINT can be used to set the backlog to a larger value than possible with SOMAXCONN.

So 5 is really really low. Although a modern OS will automatically increase the 5 to 16 or 32, I'm not sure if that's actually done here on Windows.

Now 200 or more concurrent connections is really rare in normal use, but 5 is really low and I ran into the problem using this test-code to test the original app in this topic.

[LeP]

Actually... the problem here is that fplisten uses 5 as default for backlog connections.
......
So 5 is really really low. Although a modern OS will automatically increase the 5 to 16 or 32, I'm not sure if that's actually done here on Windows.

No, in Windows this value is the value that Winsock will use, I had 5 listen sockets in my servers too in the past, to limit hacks and issues, and this is the value that Winsock used.

I tried until 50 without any issue.

P.S.: I remember in the past time (Win 95 ?) that connections limit was 5. Perhaps the value of FPC comes from that period.

[ArminLinder]

Many thanks for you helping!

I spent yesterday cleaning up the code a bit, and commented out the save file part to check whether the temp file issue is to blame.

Today I asked my students to torture the remaining code with anything they have at hand and got a wild mix of approx. 20 Windows PCs, iPads and Android Phones connecting properly and running well. At first the Program locked up after approx. 15-20 requests, but this time I captured the error (see attachment). Seems harmless to me, though I wonder what that is. Anyway, I cought the error and ignored it, and thereafter no more problems arised, the program worked like a charm.

Tonight I will reactivate the save file part again, and have the program load-tested tomorrow.

I'll keep you informed, and upload the current code tonight.

BTW, as you can see in the attachment, the HTTPRequest object returns the IP Address of the connecting client in byte-reversed order. Why this?

Armin

[Thaddy]

Because it is big endian (network byte order). There are functions to convert to litte endian native ordering.
See the functions mentioned here:
https://www.freepascal.org/docs-html/rtl/system/beton.html

[rvk]

You can consider the wrong order as a bug. There are more such bugs still in there.
Like https://gitlab.com/freepascal.org/fpc/source/-/work_items/22605

In there it has some testcode which shows that NetAddrToStr will give the exact reverse of HostAddrToStr.
So or HostAddrToStr should have been used here (instead of NetAddrToStr which is used for this error message), or the IP should have been converted depending on platform. Luckily it's just a display bug.

Host:  18.52.86.120 -> 18.52.86.120
Host6: 1234:5678:9abc:def0:0FED:CBA9:8765:4321 -> 1234:5678:9ABC:DEF0:0FED:CBA9:8765:4321
Net:   18.52.86.120 -> 18.52.86.120
Net6:  1234:5678:9abc:def0:0FED:CBA9:8765:4321 -> 1234:5678:9ABC:DEF0:0FED:CBA9:8765:4321
Raw as net:   18.52.86.120
Raw6 as net:  1234:5678:9ABC:DEF0:0FED:CBA9:8765:4321
Raw as host:  120.86.52.18
Raw6 as host: 1234:5678:9ABC:DEF0:0FED:CBA9:8765:4321

https://palma.strom.sk/doc/fpc/rtl/sockets/hostaddrtostr.html

HostAddrToStr converts the host address in Entry to a string representation in human-readable form (a dotted quad).

Basically, it is the same as NetAddrToStr, but with the bytes in correct order.

So... HostAddrToStr should have been used for display purposes (?)

[Thaddy]

You can consider the wrong order as a bug. There are more such bugs still in there.

So what is the "wrong" order? I don't get that. Where's the bug? The bug is your perception.
Network Byte Order.
For display purposes it may be a bug indeed,

[rvk]

That's what I said. It's a bug in displaying the IP.

Luckily it's just a display bug.

[ArminLinder]

I agree. A string function that returns an IP address in reversed order is a bug, in my opinion. The byte reversal should happen internally.

I doubt filing a bug report makes sense. This quirk has clearly been there for decades, and fixing it now would break too much existing code.

Armin

[jamie]

if it makes you feel any better, most likely not, the last time I looked network address segments are in Motorola format, big endian, which means from a
Intel looks; the bytes or words are backwards.


Jamie

[Thaddy]

I agree. A string function that returns an IP address in reversed order is a bug, in my opinion. The byte reversal should happen internally.

I doubt filing a bug report makes sense. This quirk has clearly been there for decades, and fixing it now would break too much existing code.

Armin

Simply ask MvC: he can add a new property or fix it. It is not much work and if he feels like it, it is likely fixed tomorrow,