PRPnet servers for NPLB

[rogue]

Originally Posted by mdettweiler

During our recently completed rally, we ran a PRPnet server for the 5th Drive on port 9000 alongside the primary LLRnet server on port 3000. It performed quite nicely, and per discussion between Gary and I we've decided to keep the server on as a permanent alternative for those who would like to use PRPnet on the drive that is to be our primary focus for the rest of the year.

Depending on how popular the server turns out to be, we'll keep it loaded with appropriately-sided ranges from the 5th Drive; at the very least we'll plan to load 1K ranges to keep it going even if it doesn't get much business. The idea is to have an alternative available at all times to the LLRnet servers that the majority of the project runs on, for anyone who finds it more convenient to use PRPnet given their specific setup.

This is news to me. Is this akin to saying that I can remove the alpha tag from PRPNet?

[mdettweiler]

Originally Posted by rogue

This is news to me. Is this akin to saying that I can remove the alpha tag from PRPNet?

Well, there's one lingering issue with a segfault that I ran into; I'm currently running the server under gdb so I can catch a stacktrace on it and hopefully send something useful to you on it. Besides that, though, it looks pretty good, so yes, once the segfault is cleared up I'd say it can probably be made non-alpha.

[rogue]

Originally Posted by mdettweiler

Well, there's one lingering issue with a segfault that I ran into; I'm currently running the server under gdb so I can catch a stacktrace on it and hopefully send something useful to you on it. Besides that, though, it looks pretty good, so yes, once the segfault is cleared up I'd say it can probably be made non-alpha.

I am not aware of any issues with 3.2.5. Could you possibly be using 3.2.4? I had fixed a segfault in that release.

[mdettweiler]

Originally Posted by rogue

I am not aware of any issues with 3.2.5. Could you possibly be using 3.2.4? I had fixed a segfault in that release.

I got the binary from Lennart; I'm pretty sure it's 3.2.5. Here, let me check...

Confirmed, it's 3.2.5. Directly prior to the segfault I see a whole swarm of log messages saying "x: client connecting from [Lennart's IP]" where each successive message increments x by one, at a rate of a few per second. x started around 710 and went until about 1020 (come to think of it, the last one might have been 1023 or 1024, which might be significant). It almost appeared that it was opening more and more sockets in some kind of infinite loop, until it ran out of sockets to open (possibly Linux has a limit of 1024 sockets?)...tell you what, I won't try to explain it here, I'll just send you the log. I was originally going to wait until I had a stacktrace before sending you anything, but now that I think about it, it's possible this is a rather rare error that doesn't show up often enough for me to get another example anytime soon, so I'd better send you what I've got.

[rogue]

Originally Posted by mdettweiler

I got the binary from Lennart; I'm pretty sure it's 3.2.5. Here, let me check...

Confirmed, it's 3.2.5. Directly prior to the segfault I see a whole swarm of log messages saying "x: client connecting from [Lennart's IP]" where each successive message increments x by one, at a rate of a few per second. x started around 710 and went until about 1020 (come to think of it, the last one might have been 1023 or 1024, which might be significant). It almost appeared that it was opening more and more sockets in some kind of infinite loop, until it ran out of sockets to open (possibly Linux has a limit of 1024 sockets?)...tell you what, I won't try to explain it here, I'll just send you the log. I was originally going to wait until I had a stacktrace before sending you anything, but now that I think about it, it's possible this is a rather rare error that doesn't show up often enough for me to get another example anytime soon, so I'd better send you what I've got.

Got your e-mail. I think something funky happened on the client side that caused it to open up a large number of sockets in the server. The server had difficulty handling that many connections. The server was never designed to handle 1000 connecting clients concurrently. Do you know if Lennart had a script that runs the client? If so, maybe that script was stuck in a loop.

Note that there are other limits that my software cannot address, such as the limit of concurrent open sockets (a TCP/IP setting in the OS) or a limit on the number of threads (an OS setting or a limit based upon available memory). I could modify the server to tell additional connecting clients to wait, but that would require a lot of work.

I do agree that the server shouldn't crash under this scenario. I can look into it and have it reject new connections once it hits a specified limit. That should be fairly easy to do.

[mdettweiler]

Originally Posted by rogue

Got your e-mail. I think something funky happened on the client side that caused it to open up a large number of sockets in the server. The server had difficulty handling that many connections. The server was never designed to handle 1000 connecting clients concurrently. Do you know if Lennart had a script that runs the client? If so, maybe that script was stuck in a loop.

Note that there are other limits that my software cannot address, such as the limit of concurrent open sockets (a TCP/IP setting in the OS) or a limit on the number of threads (an OS setting or a limit based upon available memory). I could modify the server to tell additional connecting clients to wait, but that would require a lot of work.

I do agree that the server shouldn't crash under this scenario. I can look into it and have it reject new connections once it hits a specified limit. That should be fairly easy to do.

Okay, that sounds good. I don't expect that we (or anyone else, for that matter) will ever have to deal with >1000 clients connecting concurrently, so having the server flat-out reject clients over a limit should be quite fine. The clients already handle such situations quite well, and would just try again or, failing that, move on to the next configured server.

[henryzz]

can i suggest that the retry time for clients is either changed from 10 minutes to something less or is made adjustable in the ini file
waiting 10 minutes is quite extreme a lot of the time

[mdettweiler]

Originally Posted by henryzz

can i suggest that the retry time for clients is either changed from 10 minutes to something less or is made adjustable in the ini file
waiting 10 minutes is quite extreme a lot of the time

10 minutes is what Mark has in the prpclient.ini's by default in his "master copy" downloads from his website; PrimeGrid has apparently left this intact as well for their packages. For the NPLB client packages I've generally made sure to change them to 1 minute. However, since the NPLB client packages are currently outdated and therefore the PRPnet thread points downloaders to PrimeGrid's website instead, you'll end up with whatever they've got.

I'm really busy right now so I probably won't be able to get NPLB client packages posted any time within the next week or two; it's not really high on my priority list since PrimeGrid's are virtually identical and the retry time option is easy enough to change.

[rogue]

Originally Posted by henryzz

can i suggest that the retry time for clients is either changed from 10 minutes to something less or is made adjustable in the ini file
waiting 10 minutes is quite extreme a lot of the time

Change this line:

errortimeout=10

in prpclient.ini. This is the setting that affects that 10 minute delay.

[henryzz]

sorry for missing something that obvious
i am more familiar with the server ini than the client 1

[rogue]

Originally Posted by henryzz

sorry for missing something that obvious
i am more familiar with the server ini than the client 1

It is akin to looking for a long time at a piece of source code to figure out why it won't compile only to have someone else look at it for ten seconds and point out the obvious mistake.