Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML network library vs ?  (Read 14903 times)

0 Members and 1 Guest are viewing this topic.

Lys

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML network library vs ?
« Reply #15 on: September 03, 2014, 12:51:47 am »
Sorry for bringing up this old thread. I've been using SFML in my project for quite some time now because I like the simplicity of networking, at least when I compared it to boost.asio which I used in another project.
Since my current project is a (dedicated) server software I'm wondering about the speed of the networking library so I found this thread and read this:
The only real downside to using SFML for a multiplayer game is that TCP isn't that fast (though depending on the game, that might not matter)
Now I'm wondering whether that is actually true. First of all I'm unsure what he means. Latency (very unlikely, isnt it?) or the CPU power necessary to read/send out packets? And then again, so far I've found the library to be very well implemented so I'm not really sure why there would be any unnecessary overhead in TCP sockets that other libraries do not have.
« Last Edit: September 03, 2014, 12:53:47 am by Lys »

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: SFML network library vs ?
« Reply #16 on: September 03, 2014, 01:06:37 am »
SFML itself isn't slowing anything down as far as I know.  I believe what Redx was really getting at was this:
Quote
SFML doesn't provide reliable UDP
As he pointed out, some libraries provide this.  SFML does not.
« Last Edit: September 03, 2014, 01:12:13 am by Ixrec »

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: SFML network library vs ?
« Reply #17 on: September 03, 2014, 01:29:15 am »
For very demanding applications, SFML's use of select() (as opposed to poll(); which AFAIK is slightly more scalable on some BSD's (but not as well as kqueue()) and epoll() which scales significantly better on Linux (and doesn't have the FD_SETSIZE problem) - on Windows I guess the prefered option is WaitForMultipleObjectsEx()) may be considered a disadvantage.
But, as I said, this is mostly only relevant to very picky applications and I doubt your game is one ;)

The biggest "disadvantage" of TCP is (IMHO) also its biggest advantage: a reliable, in-order, stream. Being reliable and in-order simplifies life hugely for users of the protocol, but it does mean that whenever a packet gets lost (and they do get lost once in a while) or arrives out-of-order, then you pay a latency penalty while TCP times out and then re-transmits the missing packet or re-orders incomming packets (which may mean it has to wait for some of them). UDP does not have those downsides since it's not reliable, but then it has the downside of being unreliable so you have to implement your own re-transmit logic etc on top of it if you need that.

As for reliable UDP; as lxrec already said, SFML does not provide this - maybe you want to look at ENet or a similar library for that.

Edit: also be aware of the impact that network buffer sizes can have on performance - be aware of the bufferbloat problem.
« Last Edit: September 03, 2014, 01:52:54 am by Jesper Juhl »

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: SFML network library vs ?
« Reply #18 on: September 03, 2014, 01:35:24 am »
RakNet(http://www.jenkinssoftware.com/index.html) also recently went BSD license, but with a small patent trap disclaimer.
« Last Edit: September 03, 2014, 01:37:55 am by FRex »
Back to C++ gamedev with SFML in May 2023

Lys

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML network library vs ?
« Reply #19 on: September 03, 2014, 04:36:14 am »
Thanks guys, these were the replies I was looking (and hoping) for.
SFML itself isn't slowing anything down as far as I know.

For very demanding applications, [...]
Especially yours was insightful, Jesper.

 

anything