Author Topic: 3.25 Released  (Read 22948 times)

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
3.25 Released
« on: July 27, 2008, 05:55:42 PM »
  • Added RPC3 plugin and video.
  • The second and later resends of reliable messages now occur one second apart (fixes flooding/disconnects at low pings).
  • Added templated GET_OBJECT_FROM_ID to NetworkIDManager.h which will work with multiple inheritance when NetworkIDObject is not the firstmost derived class.
  • Added char *firstDataChunk parameter to FileListTransferCBInterface::OnFileProgress callback. If you are using OnFileProgress, don't forget to update your interface or you won't get the callback any longer.
  • Fix FileListTransfer when doing endian swapping.
  • Fixes for Linux FileOperations.cpp and FindFirst (fixes autopatcher).
  • ReplicaManager2: Added GetTimeToNextAutoSerialize, fix timestamp endian swapping, multiple instances now supported on the same instance of RakPeerInterface (must use AutoAddConnections(false)).
  • Added static SocketLayer::IsPortInUse().
  • Virtual function and multiple inheritance fixes for AutoRPC.
  • Various fixes and updates for PHPDirectoryServer.
  • Change GetExternalID(UNASSIGNED_SYSTEM_ADDRESS) so that it returns a consistent external address.
  • Add boolean parameter includeDisconnecting to RakPeerInterface::IsConnected().
  • RakPeerInterface::CloseConnection() now cancels connection attempts in progress immediately and reliably.
  • Ready event plugin fixed.
  • Add operator << and operator >> to Bitstream.
  • BitStream now supports Read functions for other bitstreams.
« Last Edit: July 28, 2008, 12:36:27 AM by Rak'kar »

OvermindDL1

  • Anti-Spam Moderator
  • Hero Member
  • ****
  • Posts: 855
  • Karma: 40
  • Programmer
    • View Profile
    • OvermindDL1's Site
Re: 3.25 Released
« Reply #1 on: July 27, 2008, 08:51:51 PM »
Your link it broken, it should be video. :)
Forgot the : in http:// in other words.  Also, shouldn't html files end with html, not htm?

EDIT1:  Also, the preprocessor is not used, well, except for maybe the definition, but that is optional, it is just pure templates.  :)

EDIT2:  Yes, I am typing these as I watch the video.  I noticed that you still have a lot of overloaded functions for handling extra params, I should show you my way of templatizing that as well to any arbitrary amount with only a single call, it does require a calling of a return variable though, so you would call those variables like functions, instead of the functions themselves...  Nice to see the system being used though. :)
« Last Edit: July 27, 2008, 09:08:13 PM by OvermindDL1 »

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #2 on: July 28, 2008, 12:37:45 AM »
Yeah, thanks for the help on the system. I'm far from a Boost expert but even with the little I learned I was able to get some powerful stuff done. I expect over the new few months this system will be expanded to be even more powerful.

OvermindDL1

  • Anti-Spam Moderator
  • Hero Member
  • ****
  • Posts: 855
  • Karma: 40
  • Programmer
    • View Profile
    • OvermindDL1's Site
Re: 3.25 Released
« Reply #3 on: July 28, 2008, 05:11:25 AM »
You know how I was doing mine in the replication style, I should probably just go all out and make the standard replication system; would simplify a lot of code if I controlled the base class.

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #4 on: July 28, 2008, 10:55:25 AM »
Quote
The second and later resends of reliable messages now occur one second apart (fixes flooding/disconnects at low pings).

Does that mean that a reliable message that couldn't be delivered would be resent one second after the first send ? What was the previous delay ? 1 second seems quite long to me...

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #5 on: July 28, 2008, 12:20:50 PM »
The first send is more or less immediate.
The second send is about double the ping.
The third and subsequent sends occur about 1 second after that.

With a 2% rate of packetloss, the chances of 3 sends being needed are 1 / (50 * 50) under normal conditions. So should both sends fail, most likely it because a large block of messages can't be delivered, in which case 1 second is quite reasonable.

JoeLudwig

  • Not-a-newbie
  • *
  • Posts: 1
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #6 on: July 28, 2008, 05:01:03 PM »
It looks like the URL to download the SDK itself is wrong too.  It is this:
 http://www.rakkarsoft.com/raknet/downloads/RakNet-3.25.zip
but it should be this:
  http://www.jenkinssoftware.com/raknet/downloads/RakNet-3.25.zip


Joe

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #7 on: July 28, 2008, 05:49:13 PM »
URL is fixed, thanks.

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #8 on: July 29, 2008, 02:05:22 AM »
OK, the second send is tried after 2x ping, this seems reasonable.

May I ask what was the 3rd send delay before 3.25 ?

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #9 on: July 29, 2008, 10:20:36 AM »
Every resend used 2X ping before 3.25.

I was thinking about this and I'm going to change it to the 4th send occurring only once a second.

Code: [Select]
// The first send is immediate
// The second send is twice the ping, plug 100 milliseconds
// The third send is four times the ping, plus 100 milliseconds
// After that we only try 1 second apart - the other side is just not responding.
internalPacket->timesSent++;
if (ackPingSum==0 || internalPacket->timesSent>3)
internalPacket->nextActionTime = time + (RakNetTimeNS)1000000;
else if (internalPacket->timesSent==2)
internalPacket->nextActionTime = time + (RakNetTimeNS)100000 + (ackPingSum>>7);
else // if (internalPacket->timesSend==3)
internalPacket->nextActionTime = time + (RakNetTimeNS)100000 + (ackPingSum>>6);

You can get this out of source control

https://raknetjenkinsso.svn.sourceforge.net/svnroot/raknetjenkinsso/trunk/Source/ReliabilityLayer.cpp
https://raknetjenkinsso.svn.sourceforge.net/svnroot/raknetjenkinsso/trunk/Source/InternalPacket.h
« Last Edit: July 29, 2008, 10:36:21 AM by Rak'kar »

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #10 on: July 29, 2008, 10:28:01 AM »
What about making this configurable ? I know this would complicate the library usage. However, this seems to be very application-specific to me.

For instance, I am using Raknet for an Image Generator for a simulator, in order to synchronize several PCs linking through a gigabit network. In my case, I am pretty sure the ratio of lost packets is very low, however, if a specific packet is received more than 1s later it could be problematic (I am thinking about keyframes send every second, this would delay the whole rendering by one second instead of some fractions with 3.24).
It is unlikely to happen, but I don't feel very comfortable with this change to be honest...

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #11 on: July 29, 2008, 10:37:11 AM »
Yes, I agree. What do you think about the edit above?

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #12 on: July 29, 2008, 10:52:17 AM »
I would have preferred the previous behavior honestly (3.24).

In my case the ping value is very very low, so even 100ms is >> than 2x ping...

Maybe you could do it like this:

- 1st retry : ping x 2
- 2nd retry : ping x 2
- 3rd retry : ping x 2
then
- 4th retry : ping x 4
- 5th retry : ping x 8
- 6th and later retry : ping x 16
...

this should avoid flooding as well, no ?

I would personally avoid any constant time, I think it should be relative to network "speed" only, shouldn't it ?

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #13 on: July 29, 2008, 11:13:23 AM »
The 100 ms is there specifically for very low ping connections. With large throughputs you can overflow the Windows internal packet buffer.

What do you think about this:

First retry: 50 ms + 2 * ping
Second retry: 200 ms + 4 * ping
Third retry + : 1 second

The odds that the third retry are required at 2% packetloss is 1 / (50^3) or .0008%. At 30 packets per second it would only happen like once an hour.

The reason for this change to begin with is if the other side is unresponsive, and I did 16 X ping, it still could potentially send many times a second. RakNet uses microsecond resolution for ping times, and on a LAN 16X may still be under 1 millisecond. This was causing a bug where the other system could get disconnected for reasons such as alt-tabbing, or a big spike on the network.

Edit - this could work as well

First retry: 50 ms + 2 * ping
Second retry: 100 ms + 2 * ping
Third retry: 200 ms + 4 * ping
Fourth retry + : 1 second

You'd have to lose the first send, first retry, and second retry before it started to seriously back off by 4* the ping.
« Last Edit: July 29, 2008, 11:18:38 AM by Rak'kar »

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #14 on: July 29, 2008, 11:28:45 AM »
I understand your point.

Maybe this would be a good compromise :
- first retry -> 2 x ping
- second retry -> 2 x ping, or maybe 4x ?
- then: C + X x ping

The constants C and X could follow the scheme you proposed.

This would would ensure the same behaviour as previous version of Raknet in most of the cases (99.99%) and also limit flooding, no ?