PRPnet servers for NPLB

[Brucifer]

Okay, currently have some systems running on G2000 and G7000 and stuff seems to be rolling along okay.

[gd_barnes]

Originally Posted by mdettweiler

Hi all,

As of now, we have a new PRPnet server operational on nplb-gb1.no-ip.org port 7000, replacing the old LLRnet G7000 for the 12th Drive range.

Note that this server currently has its daily results copy-off disabled, so that the DB doesn't start importing data from it until we've cleaned up a wee bit of mess caused by some malfunctions on the old LLRnet G7000. This will be turned on as soon as Dave returns from his apparent hiatus and can get the DB stuff sorted out.

BTW, PRPnet G7000 isn't on the http://nplb-gb1.no-ip.org/prpnet/ page yet, but don't worry, I'll get it there later today.

Max

Bump bump. It's tomorrow now. lol

Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.

Since Bruce is now off of the 5th drive, I'll look to move some clients over there by tomorrow if I have an answer here.


Gary

[henryzz]

Originally Posted by gd_barnes

Bump bump. It's tomorrow now. lol

Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.

Since Bruce is now off of the 5th drive, I'll look to move some clients over there by tomorrow if I have an answer here.


Gary

AFAIK CLLR is just a console version for windows so things like PRPnet can call it from the commandline(it is identical to the latest linux llr)

[Mini-Geek]

Originally Posted by henryzz

AFAIK CLLR is just a console version for windows so things like PRPnet can call it from the commandline(it is identical to the latest linux llr)

Yep, this is correct. On Windows, LLR's GUI version is llr.exe and the command line version is cllr.exe. Either one can outdated or not. LLRnet built in a now-outdated version of LLR/CLLR. Most likely the CLLR you've got is the newer version. Run cllr -v from the command line to check. (3.7.1c is the newest)

[mdettweiler]

Originally Posted by gd_barnes

Bump bump. It's tomorrow now. lol

Whoops--sorry about that. I'll do that shortly.

Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.

As Henry said, cllr is the Linux version of LLR compiled for Windows. That gives the option of using a command line interface on Windows instead of the the default GUI. This allows the program to be run by other programs, such as PRPnet, which wouldn't be able to manage the GUI version as easily. cllr is updated along with the regular LLR, and the version included with the Windows PRPnet client packages is 3.7.1c, the latest. The Linux version of LLR, which is just called "llr" (hence the different name in the PRPnet server logs), is the exact same thing as cllr, just that it's for Linux. The version you have of that is also the latest, 3.7.1c.

In fact, cllr was actually not even around back when version 3.5, the version LLRnet uses, was current. cllr was first produced for version 3.7.1b. As such, if you have any copy of cllr, it can't be any older than 3.7.1b, which is just as fast as 3.7.1c anyway.

Edit: Ah, I see Mini-Geek explained this too while I was writing my post. One correction, though: as I said above, cllr didn't even exist for any versions slower than the current one.

[Brucifer]

G7000 hasn't been accepting stuff for a while................... can't get new work either.......

[mdettweiler]

Originally Posted by Brucifer

G7000 hasn't been accepting stuff for a while................... can't get new work either.......

Hmm...strange. The server was stuck in what appeared to be a repeating loop of "Nothing was received, therefore the socket was cloed [sic]" every few seconds. I don't have debug logging turned on for this server (the file would get really big, really fast, due to the high volume of traffic from pairs this small), and the standard log wasn't much help. All it showed was that somebody's client (or clients, it's hard to tell) connected at 16:53:07 GMT and thereafter kept inundating the server with incomplete connections that it (correctly) ditched.

Anyway, I've restarted the server now. Everything seems to be OK for now.

[rogue]

Originally Posted by mdettweiler

Hmm...strange. The server was stuck in what appeared to be a repeating loop of "Nothing was received, therefore the socket was cloed [sic]" every few seconds. I don't have debug logging turned on for this server (the file would get really big, really fast, due to the high volume of traffic from pairs this small), and the standard log wasn't much help. All it showed was that somebody's client (or clients, it's hard to tell) connected at 16:53:07 GMT and thereafter kept inundating the server with incomplete connections that it (correctly) ditched.

Anyway, I've restarted the server now. Everything seems to be OK for now.

I think I know how to solve the problem. Modify Socket::ListenForMessage() to this before returning:

b_IsSendBuffering = false;
m_Log->Debug(DEBUG_SOCKET, "Message coming on socket %d", i_Socket);
b_IsOpen = true;
b_IsReadBuffering = false;
return inet_ntoa(sin.sin_addr);

I suspect that the send buffering flag is set and is preventing the server from properly telling the client that it has established a connection. I gave this patch to Lennart and we haven't seen any new issues with it, or at least none have been reported.

[mdettweiler]

Originally Posted by rogue

I think I know how to solve the problem. Modify Socket::ListenForMessage() to this before returning:

b_IsSendBuffering = false;
m_Log->Debug(DEBUG_SOCKET, "Message coming on socket %d", i_Socket);
b_IsOpen = true;
b_IsReadBuffering = false;
return inet_ntoa(sin.sin_addr);

I suspect that the send buffering flag is set and is preventing the server from properly telling the client that it has established a connection. I gave this patch to Lennart and we haven't seen any new issues with it, or at least none have been reported.

Okay, I've applied the patch. Hopefully we won't see any more of this problem.

[Brucifer]

Okay, G7000 is hanging up again so I'm pulling stuff off. Will work on my manual reservation stuff.

[mdettweiler]

Originally Posted by Brucifer

Okay, G7000 is hanging up again so I'm pulling stuff off. Will work on my manual reservation stuff.

I just checked the server and it looks fine. I also confirmed that Gary didn't restart it, so it seems whatever the problem was, it fixed itself. I'll take a look at the debug logs later and see if it was a different sort of problem.