views:

431

answers:

4

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.

+1  A: 

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
A: 

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?

Blank Xavier
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
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.
Blank Xavier
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.
Blank Xavier
+1  A: 

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
A: 

I think Howard May has the point...looking for good sctp apps...

moliyady