Error in bitstream.h @ 144 when connecting to dedicated server

#1 I forgot to post the server output:

*** Mission loaded
Received info request from a master server [IP:63.224.200.48:28002].
Sending heartbeat to master server [IP:63.224.200.48:28002]
Got challenge request
Sent challenge response
Connection request from: IP:10.10.1.3:28000
Accepting connect... CLIENT ID = 0
Sending connect accept: 1139
CADD: 1139 IP:10.10.1.3:28000
*** Sending mission load to client: fps/data/missions/scorchedPlanet.mis
Received info request from a master server [IP:63.224.200.48:28002].

#2 Ok, thanks Garrett. Not sure off hand what this is. We'll have to try and reproduce it here. Bitstream errors are usually packet mismatch problems, which means there is probably some problem with the packet processing when connecting to the second server without a "clean" disconnect from the first.

#3 I am also getting this error, It can be reproduced by starting 2 dedicated servers and joining one of them. While in game try to connect to the other with connect().

Just confirming the error.

#4 Hmm..

Is that function getting called on the server or the client side?

A dedicated server can't connect to another server.

#5 I Am experimenting with sending the client from one dedicated server to another dedicated. I am still trying to figure out what is causing this. This error happens just as the client recieves the connection accept. I'll post more If I can figure out anything.

#6 Ok, just tried this out. Here's the scoop. NetConnection::isServerConnection, which is used to determine if the NetConnection is a connection to the server (ie, on a client), uses the static NetConnection variable mServerConnection. When a new connection to a server is initiated, it sets mServerConnection to the new connection object. So then your old connection is no longer going to get the correct value from isServerConnection, and GameConnection::readPacketData is going to read overflow the packet.

I would consider this a bug, but you're going to run into all kinds of problems if you actually try to have 2 concurrent connections to different servers. So, my advice would be to disconnect from the old server before you connect to the new.

You can do this by:
ServerConnection.delete();
connect(%newServer);

#7 Oops... that should have been ServerConnection.delete(), not LocalClientConnection.delete(). Fixed it in the original post.

#8 Thanks alot Mark for the explanation and fix! You rock.

#9 Hi Mark,

Thanks for the speedy repsonse. Unfortunately Im still having problems with this. Adding ServerConnection.delete() to the client script causes a memory read error(I can post all the details if needed). Is the correct place? Im assuming so, also Im using Release 1.1.1, should I use the HEAD version?

Thanks again,

Chris

#10 I am still having trouble with this also. With Yesterdays HEAD version,I can get it to work by opening the console of the client and entering ServerConnection.delete(); connect("192.168.0.167:28005");. By doing this I can travel between servers without any problems that I can see yet. But I've been failing to get it to work in a way similar to this:

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2421

This probably isn't the right place to ask this but, What is the proper way to have the server tell the client to disconnect from Itself and reconnect to another server. It seems logical to do it with a command to the client telling it to ServerConnection.delete(); connect("192.168.0.167:28005"); It crashes that way though, I will continue trying to figure this out.

Sorry If this is in the wrong place but it seemed to fit with the post.

Thanks,
Bruce

#11 You might try having the client schedule a function call that actually does the disconnect and whatnot. Possibly Torque doesn't like it if you disconnect inside a server/client cmd.

Josh

#12 Deleting the connection within a clientCmd would be bad - the clientCmd function will be called from within the packet receive function on that connection, so deleting the connection will likely have poor results.

Definitely want to schedule(0) this.

#13 Thanks again, currently I am testing this and seems to work pretty well so far.

function clientCmdconnectserverPortal(%Destination)
{
schedule(0,0, "Disconnect");
connect(%Destination,$Client::Password,$pref::Player::Name);
}

I pass destination from a few triggers pointed to differnt servers and it seems to work well so far.

Thanks again! No more manual disconnecting and reconnecting to the various places in my little world.

#14 Nice work Bruce!! I tested this and it works for me as well.

C

#15 The following works fine as long as I don't add port info (i.e. 131.95.xxx.xx:28001) in %desination.

schedule(0,0, "Disconnect");
connect(%Destination,$Client::Password,$pref::Player::Name);

If I want to point to different server instances on the same machine using different ports, how would I do this?
----------------------------------------
Dumb me, I was using 28001 instead of 28000 to test this. It's working--just need to point to right port :)