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.

Messages - Scorch

Pages: [1] 2 3
RakNet C++ Support / Re: Advertise System Question
« on: June 27, 2006, 11:28:10 AM »
I've never heard of a NAT server banning an incomming and not unbanning it when an outgoing goes to it, but I'll definitly take your word on that.  All of the NAT punch through documentation I have seen online didn't mention that posibility but I havn't seen everything I guess.

As for the both directions thingy, you have a point.  In my architecture, I already have everyone accepting connections and I don't care who established the connection because everyone is running RakPeer, with the same application level message set, so my assumption set is different there for my solution suggestion is different.


RakNet C++ Support / Re: Advertise System Question
« on: June 27, 2006, 12:34:25 AM »
The more I think about it, the more i'm sure that if you have both clients attempt to connect, you don't have to worry about the timing.  with the current model, you have to make sure that the receiver has finished calling advertise system before you issue a connect or it will fail.  But if both issue both an advertise and a connect, then no matter the result of the race condition, the calls will be in the right order in at least one direction, if not both.

RakNet C++ Support / Re: Advertise System Question
« on: June 27, 2006, 12:15:06 AM »
From your attempts to maintain timing I take it that the NAT servers don't keep ports open long?  I don't know what the time restrictions are on that.

I also have one slight difference, I don't care if S connects to R or if R connects to S in my architecture.

I thought if I told S and R to both connect at the same time, proving them the external IP and port of the other, then the outgoing connect attempt from both sides would set up their respective NAT servers to receive the connect.  And in the race condition created, no matter which one "won" it would set up the NAT punchthrough for the other.  There is a posibility that both clients are behind more than 1 NAT server, in which case there is still a chance to fail.  That is why I have both clients send an advertise 100 or 200 ms before attempting to connect.

Here is my sequence:

S - server
A - Client A
B - Client B

A and B are allready connected to S.

S tells A to connect to B,
S tells B to connect to A,

A receives the command and isseus an advertise to B and starts a 200 ms timer.
B receives the command and issues an advertise to A and starts a 200 ms timer.
( even though the ping may be more than 200 ms between the two, the NAT punch through part  ( about 10% of the travel time )should have enough time unless they are behind like 50 NAT servers all using satilite and modem, in which case they shouldn't play my game ).

A issues a connect to B
B issues a connect to A.

No matter who wins the race, NAT punchthroughs are set up on both sides.
for example, A wins:
B receives connect from A, and accepts it
A receives connect from B, and accepts it.

B realizes that it is connected to A twice, and consolidates the two connections to one.
A realizes that it is connected to B twice, and considiates the two connections to one.

The last part is what I'm missing.    I thought I could do it at the application layer, but apparently not.  I wanted to issue both connects at once, because if one of the NAT punch's failed, I would effictively have a "backup".   I also think that you could do this entire process in roughly 200 ms.  I studdied NAT servers in college, but its been a while, from what I can rember of NAT servers a single advertise system should convince it to set up a route in its table, I don't know if sending multiple offline messages would help.

What you described apears to be basicly the same process as is in existance now, but just has added an attempt to syncronize clocks in the process. I do not know if that will make much of a difference in connect success rate.


RakNet C++ Support / Re: Advertise System Question
« on: June 26, 2006, 10:54:54 PM »
I have more information now.
The crash part turned out to be a bad iterator on my side.  It was a side effect of what happens inside rakknet, I have that patched so it can't happen agian, but I still have the same problem.

Here is the sinerio as what I have been able to map out:

-Server Tells A : ConnectTo( B )
-Server Tells B : ConnectTo( A )
-A receives ConnectTo( B ) and initiates a connection
-B receives ConnectTo( A ) and initiates a connection
-B receives a connection from A and accepts it.
-Some application level messages go back and forth.
-B's attempt to connect to A times out, B receives: "ID_CONNECTION_ATTEMPT_FAILED" and cleans up.
-Part of that clean up ends up sending a "ID_DISCONNECTION_NOTIFICATION" to A, now A and B are no longer connected at all.

Still working on a work around related to timing, but even if I get it working there is still a window depending on pings and such.


RakNet C++ Support / Re: Advertise System Question
« on: June 25, 2006, 11:26:35 PM »
Ok, I have narrowed down the crash a bit more.

[edit] - took out one of the connects and my game app still crashes when the 2 clients attempt to connect to each other.
  still looking forward to suggestions, but I can't blame raknet for my crash ... back to the grindstone...

It is crashing if I receive a connection request from a player that I am already connected to....
since its a race condition, I don't know yet how to fix this one.  I can make the race condition less likly, but that is about it right now. ( I am going to try to add some delay on one side to make the race gap wider .. )

RakNet C++ Support / Re: Advertise System Question
« on: June 25, 2006, 11:14:39 PM »
Advertise system doesn't actually connect no, but if I emediatly try to connect after advertise system teh connect call returns false.
added printf's to rakpeer.cpp and found that it returns false because it finds it in the remote list of allready existing connections.
I tried sleeping 100ms (30ms raknet thread timer) but that had no effect.

RakNet C++ Support / Re: Wiki, mailling list, and version control
« on: June 25, 2006, 10:07:08 PM »
Also should point out the IRC channel for those who are looking for fast results...

Server:  Freenode
Room:  #RakNet

There's usually someone there and we're trying to get more members to visit.  We're trying to get the IRC channel setup as another alternative if you need help.  :)


A link on the main page to open up Freenode #RakNet would help.  ( not sure how its done, but seems to do it well )

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 / Re: Back to basics connection question
« on: April 06, 2006, 12:52:07 AM »
Dang, that is what I expected.

Wonder what could be going on in my system that would confuse this.
I doubt my router would complain about routing a packet back to the machine it came from....
I wonder if I've got a firewall somewhere I don't know about.

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 / Re: Autopatcher question
« on: April 05, 2006, 09:05:02 PM »
As for sending delta's I didn't think about that.
It would be problematic if I had to track versions and prebuild delta files.  But I would consider a subdivided shaw1, say send a shaw1 for every 10,000 bytes, overlaping by 5,000 bytes and then send only the 10,000 byte segments that were different. 
Not in my scope at the moment though.  But if I end up making any improvements to autopatcher for my project I'll be sure to let you have them if you wish.

RakNet C++ Support / Re: Autopatcher question
« on: April 05, 2006, 09:02:17 PM »
ID_AUTOPATCHER_SET_DOWNLOAD_LIST is returned to the client telling it what files it will get.  ID_AUTOPATCHER_WRITE_FILE is then sent for each file, which is sent compressed.

Does this mean that the entire file (compressed or not) is contained in one ID_AUTOPATCHER_SET_DOWNLOAD_LIST reguardless of size?

3. Preventing DOS attacks, by which a client is limited to how often they can download the same files.

 I was also considering this.  I was planning on only sending each file to each connection once per connect/disconnect cycle.   And if that became problematic I was going to then invest the time in file requests per minute per PlayerID, followed by banning after a higher limit.

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 / Re: Putting a thread to sleep untill packet
« on: April 03, 2006, 01:01:13 AM »
Doh! I feel dumb.

I was thinking about what you suggested, I already had Sleep(15) in my loop.  And you were right, that shouldn't cause 50% + usage of my processor duh.
Problem turned out to be I had logic that attempted to go "while packets to process Sleep(0) between each one, else sleep (15) to wait for more packets " .. problem with my logic was the "while packets to process" had a bug where it allways returned true, so my thread was trashing.



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.


Pages: [1] 2 3