Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Scorch

Pages: [1]
RakNet C++ Support / Advertise System Question
« on: June 25, 2006, 08:57:55 PM »
I have 2 problems I am working on right now:

The Plan:
I think I understand advertiseSystem and NAT punchthrough well enough to get this done.  I have 2 clients and a server.  Both clients are connected to the server, and wish to have a connection to each other.

Server tells both clients to advertise to the other and then connect.  (figure better odds of success if they both attempt to connect). 

Problem 1: Can't connect after calling advertise.

Since advertise creates a connection to send the advertise and then closes the connection, if I attempt to create my own connection before the advertise gets out, I get denied.

How do I know when its done disconnecting after advertise so I can issue my own connect?
Problem 2: If two clients attempt to connect to eachother at the same time, a race condition causes a disconnect (and in my system a crash but I don't know yet if the crash is mine or raknets).

Machine A issues a connect to Machine B, at the same time B is issuing a connect to A.  Lets say in this race, A establishes a connection first.  Then attempt B's connection is denied because A is allready connected to B.  The denied causes some cleanup including closing the connection to A because it thinks it failed.  Now neither are connected!

How can I tell if my attempt to connect is being denied because i had a race condition and i'm allready connected?

The only ideal solution to problem one I can think of so far is if advertise didn't open a connection to send out data (Junk data should be enough to fool a NAT server right?

The only ideal soltuion to problem two I can think of is if "allready connected" was either its own ID tag so I can handle it myself, or if "allready connected" was a successfull connect result.

[edit]  I forgot to say that my ideal soltuions have their flaws, I am not suggesting major changes to raknet, any old solution to this problem would be fine.


RakNet C++ Support / Back to basics connection question
« on: April 05, 2006, 11:49:34 PM »
Just realized that all of my tests and development so far have been on one machine using as the IP address to connect to, so I did some experiements.

I routed ports 60000 through 60100 to my machines IP address in my router NAT table manually.
I then attempted to connect to port 60020 of my router's external IP address hoping it would route the connection to my server also running on my machine ( the server was using 60020 ) .  I was not able to establish a connection.

I then tried to back up a step by connecting to my own IP address (192.168.1.XXX) and agian I was not able to connect using the same port.

I left the server running between expirments and changed my connection string IP address back to and I am able to connect every time.

Should this be working? should I be able to connect to myself using my external IP address?  Or am I going to have to go ahead and buy a second computer to connect to?  ( an expense I was hoping to avoid for a while)

RakNet C++ Support / Autopatcher question
« on: April 05, 2006, 06:14:18 PM »
I've been code reviewing the autopatch code.
Very well writtin btw.

I just want to confirm what I am seeing.

When it decides that a file needs to be transmitted to a client, it looks like it loads up the entire file and sends it out the comport all at once?  is this correct?

Also I cant tell where data is complied on the receive, does it receive the entire file as a single packet?

I am reviewing it because I plan on doing a distributed download where there are several servers running and each client download seperate files from the various connections simutaniously.  I can see that modifing autopatcher is probably my quickest option.


RakNet C++ Support / Putting a thread to sleep untill packet
« on: March 30, 2006, 12:50:38 AM »
I have several threads that do not need to do anything while there are no packets to process.  (Like my job sorter, and my worker threads).

Anyone have a good trick on putting these threads to sleep untill a packet arives?  They are chomping processor like panic'd hungry wolves.

Also, I have several instances of rakpeer in my process, and my job sorter would need to wake if any of the rakpeer objects received somthing.


RakNet C++ Support / NAT Punch-Through question
« on: March 26, 2006, 07:31:31 PM »
I've read the manual page on NAT punch through.

I still have a question.

I think this may be in the manual, i'm just not picking it up.

You have 2 machines behind NAT routers.    Each one connects to a MasterServer or some equivilant.  The Master server can look at the incomming connections and sees their real external addresses.  It then tells each machine what the external address of the other one is so they can communicate directly.

  Even if I know the external address on the other routher, How do I send it a connection request that will cause its NAT server to route the packet?  Doesn't the NAT server still have to be manualy configured to route specific incomming port addresses to the target machine?

I am going to need this feature for my project.   So I need to learn more about it.


I have 3 executables.
Executable A is a client to Executable B.
Executable B is a client to Executable C.
The connect code is in a dll, common to all processes.

A can connect to B just fine, and when it does it gets back a "CONNECTION ACCEPTED" message.
But when B then connects to C, I get back only "STATIC_DATA", never a connection accepted.

Anyone know of a case that can cause this?

Feature Requests / User Packet ID start
« on: March 14, 2006, 01:43:50 PM »
Rakkar, I was knowticing that you have several ID_RESERVED_N identifiers in your packet cmd value code,
and in your example video you used ID_RESERVED_9 + your own index to get a valid value. 
What I would like to recomend is you add a ID_USER_ID_START to this enumeration list, and define proper usage of application/user level enumerations to start with this value and allways add.  For example

Code: [Select]
// note this is pseduo code, I havn't tried to compile this //
typdef enum
         CMD_PacketStart = ID_USER_ID_START,

#if  CMD_TOTAL_IDS > 256
   #error "To many CMD values"

Then when you add in new PacketID's in your rakknet internal development, you just need to increment up ID_USER_ID_START, and when people re-compile with your new code, they won't end up duplicating command values, and you won't have to risk running out of reserved numbers as much.

Of course, I think you could come up with a better name than "ID_USER_ID_START" ... i'm not very good at comming up with creative variable names.

Just an Idea ... not critical to my project.

Feature Requests / Amazing feature request response time!
« on: March 08, 2006, 12:16:08 PM »
I saw the realase notice for version 2.456, I didn't want to clog up a release notice with my comment so I'll post here.

I just wanted to say I am impressed with your reaction to feature requests rakkar!  You did alot of those features within a day or two of request, and in many cases, you updated cvs same day! Impressive!

Btw, on a side note, I've been meaning to ask, where did the name Rakkarsoft come from?

Feature Requests / << and >> operators for bitStream
« on: March 06, 2006, 07:54:01 PM »
I use my own MessageStream class (simular to bitstream, less compression)
The bigest thing keeping me from converting to bitstream is the insertion and removal methods.
If it really is a true stream, could you add << and >> operators to it?

The << and >> operator support makes it easier for me to write operators for my message types so my message handling looks like this.


Code: [Select]
UpdatePositionMessage ToSend( playerID, position, volocity); // constructs a C++ structure containing my message data
bitStream << ToSend;
// normal bitstream send code here
Then on handling:

Code: [Select]
case UpdatePositionMessage_enum:
   UpdatePostionMessage Received;
   bitstream >> Received;

Or like that.

This is effectively what I do with messagestream.
UpdatePostionMessage's >> and << operators call the >> and << operators for all its member data (like position and direction) and then they call theirs etc, untill it all becomes plain old data.

It is also a really nice way to handle compelx data that can't be memcopied.

« on: March 06, 2006, 01:12:53 AM »
I don't know how to tell which version of Raknet I am using, (I used a sdk download, maybe a month old by now)
All of the raknet examples work just fine, but When I integrate into my own code I get the following response when attempting to connect:


Here are some code snipits:
(the object "rakPeer" is a boost smart pointer)

The Server:
Code: [Select]
rakPeer.reset( RakNetworkFactory::GetRakPeerInterface() );
std::cout << "rakPeer->Initialize(" << MAX_CLIENTS_PER_EXECUTABLE << ", " << portNumber << ", 30);\n";
bool success = rakPeer->Initialize( MAX_CLIENTS_PER_EXECUTABLE, portNumber, 30);
std::cout << "return value = " << (success?"True":"False") << "\n";
rakPeer->Initialize(200, 60000, 30);
return value = True

Code: [Select]
rakPeer.reset( RakNetworkFactory::GetRakPeerInterface() );
std::cout << "rakPeer->Initialize(" << 1 << ", " << localPortNumber << ", 30);\n";
bool success = rakPeer->Initialize( 1, localPortNumber, 30);
std::cout << "return value = " << (success?"True":"False") << "\n";
std::cout << "Calling Connect\n";
std::cout << "rakPeer->Connect(" << HostIP.c_str() << ", " << portNumber << ",0,0);\n";
std::cout << "return = "
              << (rakPeer->Connect(HostIP.c_str(), portNumber,0,0)?"True":"False")
              << "\n";

rakPeer->Initialize(1, 60001, 30);
return value = True
rakPeer->Connect(, 60000,0,0);
return = True

... (a few seconds later)


If I start the client without the server, then I only get the ATTEMPT_FAILED message back, so I think I'm half right here somewhere.  The server never receives any messages, I made sure I was calling the receive() function to get a packet , and I am. 

Any ideas?

Pages: [1]