Author Topic: 3.25 Released  (Read 26520 times)

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #30 on: August 04, 2008, 02:54:29 AM »
That is not my taste, really, nor the customer's one. But thanks for the suggestion anyway. Doesn't really help however.

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #31 on: August 04, 2008, 12:07:14 PM »
Feel free to change the code as I previously suggested to match what suits your application. Be sure to monitor RakPeer::GetStatistics because you will get 50% packetloss and degraded performance by waiting on the strictly average ping.

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #32 on: August 05, 2008, 02:49:32 AM »
Yes, I will do some experiment, thanks !
BTW, which scheme did you finally selected and put in the source repository ?

Rak'kar

  • Administrator
  • Hero Member
  • *****
  • Posts: 6895
  • Karma: 291
    • View Profile
    • RakNet
Re: 3.25 Released
« Reply #33 on: August 05, 2008, 10:00:27 AM »
15 milliseconds and 1.5 * your ping.

KungFool

  • Not-a-newbie
  • *
  • Posts: 2
  • Karma: 0
    • View Profile
Re: 3.25 Released
« Reply #34 on: August 07, 2008, 07:34:50 AM »
Hi there,
I didnt quite find the right spot in this forum to post "bugfinds".
I just found a little unneeded source in the sample for RPC3.
Not like its a biggy, but if you have professional clients, you might as well have beautiful source. :]

Now in the file RPC3Sample.cpp at line 147:

Code: [Select]
rpc3Inst.SetNetworkIDManager(&networkIDManager);
NetworkID idZero, idOne;
idZero.localSystemAddress=0;
idOne.localSystemAddress=1;
rpc3Inst.SetNetworkIDManager(&networkIDManager);

there is a second call to SetNetWorkIDManager. Not really needed I guess.

Regards,

Jan

Oliver Smith

  • Full Member
  • ***
  • Posts: 173
  • Karma: 7
  • Oliver Smith
    • View Profile
    • Oliver's blog
Re: 3.25 Released
« Reply #35 on: August 09, 2008, 06:14:43 AM »
But a dropped packet would also be very rare on such a network (if the router is half-decent), so it is not a situation that would be encountered often...

Actually, even on a high-end PC running any of Windows / Linux / OSX ... you can expect to see somewhere around 0.01% packet loss to/from localhost in a processing-intensive app that generates/receives a lot of traffic.

But this raises another, valid point.

Our servers have public-facing RakNet interfaces, on which the connections are likely to have 40-700ms pings and a broad range of bandwidth/loss conditions. But they also have another instance of RakPeer which they use for a host-to-host network, via high-end gigabit network cards to a dedicated Cisco 2960.

Raknet can be as aggressive as it likes on the LAN, more is better; but for WAN connections I'm concerned that aggressive retransmits will mean a user who experiences a temporary drop in available bandwidth (Sun's JRE updater kicks in, Windows Auto-Update kicks in, Vista goes off and downloads a news feed, etc) that retransmits will compound the problem and cause a disconnect.

OvermindDL1

  • Anti-Spam Moderator
  • Hero Member
  • ****
  • Posts: 855
  • Karma: 40
  • Programmer
    • View Profile
    • OvermindDL1's Site
Re: 3.25 Released
« Reply #36 on: August 09, 2008, 09:07:36 AM »
Which gets back to the point of Rak'kar wanting to balance it for the common-case scenario.
And I just rapid-pinged another computer on my network for 100k packets, none-dropped.  :)

gjaegy

  • Jr. Member
  • **
  • Posts: 76
  • Karma: 1
    • View Profile
Re: 3.25 Released
« Reply #37 on: August 09, 2008, 03:45:29 PM »
Or make it configurable so that everyone is happy... I don't see one unique scheme that would suit every different cases...

OvermindDL1

  • Anti-Spam Moderator
  • Hero Member
  • ****
  • Posts: 855
  • Karma: 40
  • Programmer
    • View Profile
    • OvermindDL1's Site
Re: 3.25 Released
« Reply #38 on: August 10, 2008, 03:22:55 AM »
That adds another variable though, memory reads are very slow, and you generally want this kind of stuff as fast as possible...

Sorry, been doing some assembly recently so I am in an optimizing mood. :)