|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 29.05.2008, at 16:52, Jens Alfke wrote:
SCTP is not supported in MacOS X at the current time by Apple but there are others who did the hard work:
There is a userland implementation (www.sctp.de) which has its limitations mainly due to multihoming (Userspace has no control over which interface packets get sent out) and of course the limitation that if your Application crashes, the peers are left in a undefined state and might take a while to recover if you restart your application.
There is a kernel space impelmentation (patch to kernel) and a KEXT implementation.
The KEXT implementation depends on a Kernel API which is not public to attach a protocol on top of IP. So the drawback is that the KEXT is kernel version depenent and for every 10.5.x you need to produce a new version (or like since 10.4.6 simply update the plist file to adapt to the newer version of the kernel API).
Its written by Randal Steward, Peter Lei, Michael Tüxen and a few other experienced folks. Names you will find on some SCTP related RFC's as well.
That version can be checked out from CVS by doing:
cvs -d email@hidden:/usr/sctpCVS co .
You can build it in Xcode from project file in KERN/nke/sctp_nke/Tiger or KERN/nke/sctp_nke/Leopard/.
To install you need to put the following files into place:
File /System/Library/Extensions/SCTP.kext/Contents/Info.plist must have the correct kernel version or the extension wont load. To load the kernel extension use kextload.
I can also provide an SCTP.pkg which includes a startup script to load it at boot and automatically patch the plist for the likely case there will be a 10.5.4 one day and the API has not changed.
We used the userland implementation for our SS7 GSM-MAP stack a few years ago but moved on to the kernel SCTP extension. The Kernel SCTP is same source as in FreeBSD kernel now (and I think NetBSD too). It is in stable state. We use it daily to transport millions of SMS and we did not had any issues with it since its adaption to Leopard. SCTP is mandatory in many telecommunications areas which is our core business.
For the Apple folks reading this list, Radar #3800302 is the key one which is unfortunately over 3 years old by now.
Its time for Apple to roll in SCTP into the kernel in my opinion. I've had discussions about this with various folks at WWDC 2005/WWDC 2006 and probably again at WWDC2008. The problem with the kext is that there is no public API to install a protocol on top of IP. As there are not that many protocols out there and not likely many coming, that API has always been kept internal but in fact hasn't really changed since 10.4.3 (which saved our lives). So either that API has to be made public so that SCTP implementation won't stay kernel version dependent anymore or Apple adopts it and makes it part of the OS (which I think would be the smarter idea).
A definitive Yes. Some applications require it mandatory.
NAT is possible to do with SCTP. I'm not too sure if the KEXT implementation has NAT support yet but I know that there has been some code work recently in that direction in the way of MacOS X Server being a NAT server. Passing SCTP through "traditional" NAT should be possible if that NAT can deal with SCTP and if the application on top can deal with that. For example you would have to present your outside IP's to the remote while using the inside IP's. Depends a little bit on the application case.
SCTP can communicate over multiple interfaces and is multihoming and multipath aware (smart for EDGE versus WLAN for example...), so it has to communicate with the peer about its IP's and thats where NAT can interfear.
Best way is to avoid NAT and use IPv6 which is supported by the KEXT and the userspace impelmentation. IPv6 is starting to be widely available in Europe.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
|>SCTP? (From: Jens Alfke <email@hidden>)|
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.