2

I am considering using SCTP instead of TCP for a p2p app written in C. Should I do it? Also how does the speed of SCTP compare to the speed of TCP?

EDIT: I found that SCTP can be tunneled over UDP with the only problem being tunneled SCTP is not interoperable with untunneled SCTP.

sigjuice
  • 28,661
  • 12
  • 68
  • 93
andreasw
  • 511
  • 9
  • 21

3 Answers3

4

Have you considered whether your target systems will all have SCTP pre-installed on them or whether your application will need to include SCTP itself? In my experience I would not expect all systems to have SCTP installed on them, and I would expect them not to if it were Windows.

If you include SCTP in the application itself then that will more than double the number of messages being passed into an out of the Kernel which will impact performance when compared with using the pre installed TCP.

Have you considered what benefits you want from SCTP? You mentioned fault tolerance but for this to work with SCTP it requires the application to have multiple ethernet ports and and IP addresses. Is this likely on your app?

As much as I love SCTP (!) I would seriously consider sticking with TCP unless you are sure SCTP is needed or unless you control the hosts your app is deployed on.

Regards

Howard May
  • 6,639
  • 9
  • 35
  • 47
1

If it's for a local area network, sure go for it.

Note however that if you plan to use it on the open internet many consumer grade firewalls aren't flexible enough to permit unrecognised IP protocols through them.

Alnitak
  • 334,560
  • 70
  • 407
  • 495
  • OP asked also about SCTP tunneled over UDP, does this resolve the problem with firewalls? what about hole punching for NAT traversal? is it possible in case of SCTP? – Andriy Tylychko Jul 08 '11 at 13:46
  • Tunnelling would solve the firewall problem. Hole punching would depend on the tunnel running on a consistent well-known port. – Alnitak Jul 08 '11 at 13:48
  • 1
    See http://tools.ietf.org/html/draft-ietf-behave-sctpnat-05 for the current state of SCTP over NAT and the proposal to fix it. SCTP has poor protocol support at the moment, and actual implemented support is worse -- to the extent of not working with many consumer grade devices. – Bwooce Sep 25 '11 at 05:56
0

How does it help you?

You're P2P, so every peer must have at least one socket open to every other peer.

If you've got a socket open, then you can do everything you need to do over that. If you've taken the approach of one socket per file and you have multiple files being tranferred concurrently between two given peers, then SCTP will save you one socket per file. However, on a normal P2P network of any size, you will almost never have multiple files being transferred concurrently between two peers.

Just have one socket and have your own little protocol; send a packet with a header, the header indicates content type, e.g. a command, or part a file - and if so, which file, and which byte range.

Of course, you get a little overhead for that, whereas if you have one socket for commands and one per file, you're more efficient. Is saving one socket per peer (assuming one download at a time) worth the time/hassle/complexity of using SCTP?

  • Once I learn all the ins and outs of SCTP I think it would be simpler to use SCTP because it takes care of many issues for me such as fault tolerance. SCTP has smaller packet headers (to my knowledge) so this would reduce the overhead of making many small requests. – andreasw Mar 28 '09 at 17:23
  • Packet loss is so rare an event it does not justify using SCTP over TCP; all you gain is a couple of seconds of continued throughput on the other connections, *if* you're concurrently transferring multiple files to the same peer. –  Mar 28 '09 at 21:48
  • As for smaller headers - I suspect you will end up using UDP anyway. If you have five or ten thousand queued peers, you won't be holding a TCP/SCTP socket open to them all. You'll merely keep in touch with the odd UDP packet now and then. –  Mar 28 '09 at 21:51