dont worry about that, thats all handled through the TCP protocol.
Yep, but I do worry because the Checksum error is something that shouldn’t happen - and does not happen with all other packets transmitted and received within the past hour…
Seems to be a problem with the implementation you/we used…
…now I am getting sad…
After some weeks work of “pimping my server” I wanted to test it “in the wild” - means: put the server @ a dedicated root and let the client try to connect to it…
Here at the local network 192.168.x.x everything is fine… but only as long as all clients/server are in the same subnet or/and there is no gateway between them…
What is the problem? Well, The server works as suspected. He uses the IP given and he accepts incomming transmissions (tried telneting it and the server told me “got new connection”). Now I let the Client connect to the server, but the client cowardly refuses to set up the connection (with everything set up properly). I did a tcpdump at the server and got the following result:
13:45:59.961455 IP 38-203-116-85.32845 > 213-239-209-253.9099: S 4261624326:4261624326(0) win 5840 <mss 1452,sackOK,timestamp 2130652 0,nop,wscale 0> 13:45:59.961619 IP 213-239-209-253.9099 > 38-203-116-85.32845: S 2229722743:2229722743(0) ack 4261624327 win 5792 <mss 1460,sackOK,timestamp 4600066 2130652,nop,wscale 2> 13:46:00.011241 IP 38-203-116-85.32845 > 213-239-209-253..9099: R 4261624327:4261624327(0) win 0
(I removed the DNS part, otherwise the lines would get far too long…)
Can anybody of you handle this? It seems as if the windows (win 5840 and win 5792) won’t match and thus the server/client can’t connect to each other…
But I am wondering why this is working in a local net - or even throught the internet… I guess my problem is, that the client thinks it has IP 192.168.x.x instead of 18.104.22.168 (here)…
How to solve that issue?
Help very much appreciated
Edit: Uh… I left the core of the server the way Yellow made it… so it connects using the method Yellow used here… but at the server I don’t even get the message that he got a new connection (what is normal because he was not able to establish the “desired” one from the client)
Could there be a firewall blocking traffic somewhere? For instance, Windows Firewall, or a firewall in your gateway box?
Nope, tried that also… but Yellow found the problem…
self.Connection = self.cManager.openTCPClientConnection(IP, PORT,1)
it should be
self.Connection = self.cManager.openTCPClientConnection(IP, PORT,1000)
Thats a 1 milisecond connection timeout… no wonder, that the client got no reply within 1 msecs in a Environment with a DSL connection
But of course, your idea was one possible solution. Thanks for your time trying to figure out, drwr.
Same to you, Yellow… was a great help
Edit: The work is done! The server/client system is far from completion, but I wanted to have the system as “basic” as possible before adding very game specific sections to it…
- See the showcase
As for the Checksum error, I’ve seen the same issue on some python TCP networking code I wrote (unrelated to Panda3D, used the Twisted framework), and it also showed the incorrect checksum in Ethereal. I wouldn’t worry about it, however, as that code always worked fine for delivering the data, so I’d say it’s probably more an issue with Ethereal.
When I tried either the server.py or client.py code, it always conplained the following error:
Traceback (most recent call last): File "server.py", line 56, in ? class Server(DirectObject): TypeError: Error when calling the metaclass bases module.__init__() takes at most 2 arguments (3 given)
Looks like an import error due some changes in Panda3D structure… with what sort of Panda3D release did these errors occur? This software was written / tested using Panda 1.0.5 when I remember correctly… maybe you want to check that first - in case its working there, its an import problem like we do have them from time to time with a new release.
If its not - well, dunno… - hit me
Actually, that looks like a change in the way DirectObject should be imported. Make sure you are doing:
from direct.showbase.DirectObject import DirectObject
and not something like:
from direct.showbase import DirectObject
Or that way
Question is: Was that a mistake in the server.py code I did when working with the stuff or were that changes to Panda3D made later on? wonders
Even if I modified (actually I added it since it didn’t exist) the line about DirectObject, it still complained about the same message.
These are the import statement written in server.py:
from pandac.PandaModules import * import direct.directbase.DirectStart from direct.showbase.DirectObject import * from direct.distributed.PyDatagram import PyDatagram from direct.distributed.PyDatagramIterator import PyDatagramIterator
Be sure you put the DirectObject import statement after the line that imports DirectGui. In fact, make sure it’s the very last import in the file. In versions of Panda prior to 1.3.0, importing DirectGui would inadvertently (and incorrectly) import DirectObject as a module.
Amazing! It’s working now…
Following a trail of clues scattered around this forum I updated the Feature-Tutorials–Networking from the 1.0.5 release to work with the 1.3.2 release and even fixed a little bug . This is the latest thread from which I got some info, so I’ll post my result here.
You can get the updated Tutorial here:
phys.uu.nl/~keek/panda/Featu … ing.tar.gz
Hey, I hope this topic isn’t too old to dredge up.
I was running through this thread as a means of trying to teach myself the Panda3D networking and followed all the steps thus far (even all the corrections) and still cannot get the server to run.
I keep getting the following error when running the server:
F:\dev\s-c_testing>python trial_server.py DirectStart: Starting the game. Warning: DirectNotify: category 'Interval' already exists Known pipe types: wglGraphicsPipe (all display modules loaded.) :util(warning): Adjusting global clock's real time by 2.23452e-006 seconds. :net(error): Unable to open TCP connection to server 127.0.0.1 on port 9099 Traceback (most recent call last): File "trial_server.py", line 242, in <module> aClient = Client() File "trial_server.py", line 51, in __init__ self.cReader.addConnection(self.Connection) TypeError: ConnectionReader.addConnection() argument 1 must be Connection, not NoneType
I looked up the culprit line:
self.Connection = self.cManager.openTCPClientConnection(IP, PORT,1000)
They seem fine to me though.
Looking through the Panda3D API I found the method call:
openTCPClientConnection PointerTo< Connection > ConnectionManager::open_TCP_client_connection(NetAddress const &address, int timeout_ms);
Which is exactly as it is in this code sample.
So I’m strugling to find the issue.
It actually means self.Connection is equal to None, and that’s why it doesn’t like that. You have to look before that line in your code to see how it can be None instead of a Connection instance.
maybe you wanna have a look at this -> https://discourse.panda3d.org/viewtopic.php?t=4881
its pretty clean and lean thus easier to understand.
I included the culprit line up above.
For some reason ‘self.cManager.openTCPClientConnection(IP, PORT,1000)’ is returning ‘None’.
Now that is a failed connection is it not?
Or is it an issue with the usage of that function/method?
Now that I have been able to look at that other network code in detail I actually find this sample easier to understand.
It all seems to make sense to me.
Just not sure why it wont work. lol.
EDIT: Ahhhhh took a look inside his Client.py code and found that it is just this same code bundled differently (in essence).
Interestingly when he uses the EXACT same lines in Client() it works.
But in this example it does not.
Still cannot work out why as there is almost no difference.
Hi. You took a look into what client py?
If I need to fix stuff, I prolly will. Actually I need some help because that code is oldish. but once I know what I have to fix, I will do my best to DO so.
I don’t program to that extent I am used to, so I am out of training. - and my time doesn’t allow me to work back into the code. Sorry, I hope you understand…