The server and everything starts OK. Although, the server sends no greeting when I telnet in… In the past version it gave a binary greeting… The server is started with this line:
And I know it’s not much of a problem on my end, because the chatroom demo in 1.0.0 doesn’t work either… I mean to upgrade, but I don’t want to overwrite my previous Panda3D… Any help?
Ok, it doesn’t work with 1.0.2, either… You set up the server, try to connect
with the repository and the connect call takes forever. And, if you do telnet,
you don’t get any binary greeting…
Is this my computer, my method, or Panda?
The chatroom sample used to work on this computer, though, in Alpha, but here it doesn’t…
Are you running both the server and the client on the same computer?
The windows operating system is very bad about allocating CPU time. It will give ALL the CPU time to one of the two programs, and none of it to the other. There’s a way to get around this: put a
base.setSleep(0.05)
Into both the client and the server. That will keep them from hogging the CPU.
Even with that call, it takes as much as 30 seconds to connect. I don’t know why that is, I haven’t debugged it.
Wait–the same program? As in, you fire up Python once, create a server, and then within the same Python process you create the client to connect to it?
If that’s so, that would certainly cause you problems, since Python is single-threaded by default (and Panda would prefer that you kept it that way). So when your client is connecting to the server, the client is blocking, which also blocks the rest of the program from running (including the server).
But you say you are unable to run chatroom.py. Surely you are running the client and server for chatroom.py as separate instances of the same program? In two different windows?
Yes, I am. But what’s odd… It used to work with the Client and Server within the same process without connect delay. I don’t run a “Client” on the same process, per say. But the “Client” is what creates the AI and manages it.
Ok, I see what’s happening now. This is actually a problem with OpenSSL, the third-party library that Panda uses for certain kinds of network communications.
To work around the problem, put the following in your Config.prc file:
early-random-seed 0
Be sure to put this in your personal Config.prc file, or in the c:/Panda3d-1.0.2/etc/Config.prc file–don’t put it in the config.prc file in the samples/chatroom directory, since that file is apparently not being read.
David - just so you know, our sample program (chat) does create a client and a server in a single process. Is that wrong? I wasn’t aware that these repositories were using threads under the covers. It seems to work okay for the chat program.
Oh, I misunderstood you. It’s using a blocking connect call. Could we just convert that to use a nonblocking connect? It really is useful to be able to put the server and the “master control client” into a single process.
Right; I was mistaken about the blocking connect. It is already using a nonblocking connect call. The real problem here is not a timeout on connect at all; it’s due to the way OpenSSL initializes its random seed on Windows. It does this by walking through the entire heap of allocated memory, adding all the bits it finds into a hash as it goes.
A typical user of the OpenSSL library, apparently, is a relatively small program that initializes its random seed early, when the heap is small or empty. However, a Panda application, running within Python and having already opened a graphics window and started rendering, may have over 100 megabytes in its dynamic heap by the time it creates the HTTPClient object (which initializes the OpenSSL library). It is this random seed generation that is causing the 30 second delay.
I wrote a message to the OpenSSL forum when I discovered this problem a couple of years ago; I even suggested a patch to fix the problem–but my posting was never replied to; I guess they had more important problems to worry about. I guess I should try again sometime.
In the meantime, the workaround I suggested above disables the automatic initialization of the random seed (since you only need the random seed if you are going to be performing https or encryption functions). I’ve also checked in change to the Panda trunk to make this the default, and to move the initialization to static init time, which is a little better.