Slashdot Mirror
Better Networking with SCTP
5-0 writes to tell us that IBM DeveloperWorks has an interesting look at the key features of SCTP in the Linux 2.6 kernel and the ability to deliver multi-streaming. "SCTP is a reliable, general-purpose transport layer protocol for use on IP networks. While the protocol was originally designed for telephony signaling, SCTP provided an added bonus -- it solved some of the limitations of TCP while borrowing beneficial features of UDP. SCTP provides features for high availability, increased reliability, and improved security for socket initiation."
How long do you think it will be before this is adopted into the mainstream?
"I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
The article makes SCTP sound like it's the greatest thing since sliced bread. It's as fast as UDP, reliable as TCP, and is not susceptible to SYN floods like TCP. It's amazing! It's the fastest, it's the quickest, it's the best!
Really?
Multi-homing with a builtin heartbeat? Youd need a routing table the size of the planet if you wanted to do that over the backbone infrastructure- not to mention gigabytes of wasted bandwidth. Did I miss something?
In other words, it started out in the hands of AT&T, Bell Labs, Northern Telecom, Alcatel, et. al.
I do not fail; I succeed at finding out what does not work.
From the article:
It seems that that you could still have DOS attacks based on INIT floods. The client has to open a socket, generate a cookie (slight increase in computing overhead), and then listen. I see no intrinsic mechanism to eliminate these types of attacks. Technicaly, they would not be SYN floods, but INIT floods.
This is about as useful a distinction as Bush apologists denying he was warned that the levees would be breached because the tapes show him being warned that the levees would be overtopped.
Second City Transport Protocol!? John Candy would be proud!
It is nothing that wasn't already being done with UDP already. So they could have just put that into a library api and that would be that. Putting it into the protocol stack just means part of it now runs out of interrupt handlers to improve performance. But putting more stuff into interrupt handlers slows down everything else. Which means even more stuff being moved into the kernel and interrupt handlers. More crap mostly since it's such an easy and cheap way to boost performance rather than figure out how to do it properly anyway.
This is what I always wanted, but never had the time or resources to develop...
Ok, remains to be seen if it gives any real, measurable advantage in practice.
That's total bullshit. MS has nothing to do with this. In fact, no-support of SCTP in MS operating systems will be thee biggets hurdle for the introduction. It's *Linux* that is driving ther adoption !
Disclaimer: I'm using SCTP in my job for several years now.
Please add the following to your /etc/services:
tallmatthew 25/sctp
I *said* you could standardize the solution by putting it into a library api. But you seem to think for some reason it *has* to go into the kernel in order to become standard. It doesn't.
"SCTP [...] has found its way into all major operating systems including GNU/Linux, BSD, and Solaris. It's also available for the Microsoft® Windows® operating systems as a third-party commercial package."
FYI,
p hp
http://www.altoriopreto.com.br/mestrado/index_en.
TCP is totally freaking awesome. It's as fast as UDP. It's totally reliable. Only bad implementations are susceptible to SYN floods anymore. It's amazing. It's fast. It's the best. It's ubiquitous. It's mature. It's the bee's knees.
Developers! Developers! Developers! Developers!
STFU, noob.
I feel the same but thats only a question of using the right software. Gaim post 1.5 will include Video support. Current aMsn release offer you all MSN 7+ features (like handwriting, custom smiles and that thing that shakes the window) and it does support WebCams and Audio. Wait! You can still fell left behind because in fact we (Linux users) still miss many nice application only avaible to Windows and Mac users. Btw, read my my last 3 blog entries about some Linux problems: my blog
Seems like there is an implementation for FreeBSD and Darwin (underlying OS used by MacOS X) too, according to this page.
Jumpstart the tartan drive.
A while ago I read the RFC. It is very scary. Multihoming as proposed moves things like name resolution into the kernel.
I will grant SCTP does some neet stuff, the best is that it allows independent non-mutually-blocking streams over one connection. It also has state cookies, yum.
SCTP tries to be all things to all people in one protocol. It reads as though they just decided the whole layered protocol thing was overrated and shoved every new feature into this one layer.
The Linux network stack is having tons of new things lately, SCTP is one, but how it compares with DCCP, which has also been implemented and merged in Linux?
The wikipedia assumes they share some properties, but it's SCTP a better DCCP, or what?
There're many system supporting SCTP according to this page. Solaris and BSD with a external patch, for one, even there're windows implementations. But as usually, Microsoft, the "top 1" software company in the world isn't providing an implementation.
There's also Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP. Each with their own advantages. Check out the site. These guys are doing interesting evaluations. H-TCP is specifically what they work on:
TCP Evaluation Discussion
Interesting plots too
The end result is that TCP is not particularly suited to high-speed networks.
What the fuck are you on about? SCTP has nothing to do with microsoft, jackass.
I think they lost a great chance here to make transitions from IPv4 to IPv6.
A new Protokoll, based on IP, would have the chance to allow a new Socket interface. Functions could have been changed in a way, that hides the fact that you are dealing with IPv4 addresses. This would have allowed programs, that were written for SCTP, to easily transit to IPv6, without changing any of the programs code.
Current TCP Socket interfaces expose way too much of the fact that they are IPv4 based. All addresses and structs are IPv4 based, thus a transit to IPv6 would require either a IPv4 emulation layer, or many changes to the applications.
additionally, application designers would probably prefer SCTP over TCP or UDP, if the advantage of a easier transition was there.
I may run Linux myself, but in almost everything I do on my desktop (that isn't itself Linux-related) I am interacting with non-Linux machines. I'm forever "losing out" because I can't receive MSN special features. Sure I could do webcam with what was gnomemeeting (it looks awesome) but does anyone run it? Thankfully now I have friends riding Firefox and one using Jabber (googletalk).
But yes all my friends use windows!
So will such features help Desktop Linux?
Short answer: It might "help Desktop Linux" in general, but it will fix zero interoperability issues and it will do nothing to the problems you listed.
Long answer: You need to learn a few things about network protocols, my friend. Even if SCTP, TCP or UDP had anything to do with your problems, SCTP is not implemented on Windows. Most if not all of the programs you're using use TCP or UDP, and the issues of compatibility you're experiencing have nothing to do with these protocols. The programs you mention have their own protocols that run over TCP and UDP. Seriously, go and learn how to program BSD sockets and you'll understand where TCP and UDP are in the network protocol heirarchy. Once you've done that, maybe you could help out projects like Kopete and Gaim to fix your problems.
I have discovered a truly remarkable proof of this theorem that this sig is too small to contain.
I'm not geeky enough to understand what all this means but if it means net traffic will get better then I'm all for it. However, based on the responses so far, SCTP vs TCP is starting to become another vi vs Emacs, PHP vs Perl debate that all /. articles seem to follow. Won't someone please think of the packets! :)
Well, there's spam egg sausage and spam, that's not got much spam in it.
http://ezine.daemonnews.org/200602/apple.html
Thanks Apple! Oh and before you cry Troll about the article do some basic research on the author.
Can someone explain to me how the 4-way handshake is better than the 3-way handshake. I mean, sure the resource allocation has been moved down the process, but a client bent on DOS could still flood the server with INT packets and then just follow up with COOKIE-ACKs, all the while actually not allocating any resources on its side, and you would have the same end result.
Now, if the COOKIE-ACKs required some signficiant processing (like encryption with a public key) then I could understand how this would reduce DOS potential.
...En að Besta Sem Guð Hefur Skapað Er Nýr Dagur
As XP says about designing ahead of time like you are doing here: You Ain't Gonna Need It. There is no point in preparing for the future, as you cannot predict the future. If it is a customer requirement it's different, but you should not waste time on reacting to things that may not happen at all. Just make sure your units are easily refactorable and have good unit test, then it will not be hard at all to change one layer. If you don't, no -prepared for everything toolkit- will save your ass anyway.
This space is intentionally staring blankly at you
For all its problems TCP/IP is everywhere. This fact has made it the networking technology to use even when it doesn't make technical sense. For example, folks use it in high performance computing and in storage (iSCSI) where there are much better methods available technically. Its commonality (along with ethernet's popularity) often make TCP/IP over ethernet the cheapest solution to many problems (while not the best).
I used to work on InfiniBand where the reliability/congestion detection protocol (Reliable Connected and Link Level flow control in IB terms) are in hardware. This scales to 20 Gbit connections between hosts quite well. Other examples of hardware protocols include myrinet (invented by myricom) and qsnet (from quadrics) and scalable coherent interface current pushed by Dolphin Interconnect. All of these folks struggle to compete with good old TCP/IP over ethernet. Except for the parts of the HPC world, TCP/IP over ethernet wins. In the storage landscape, Fibre Channel, SAS, and SATA seem to be holding out but iSCSI sure is trying.
The performance issue is real though and very few systems can saturate a 10 Gbit TCP/IP etnernet link without massive host CPU overhead. One solution floating around is that instead of trying to make new protocols to replace TCP, we should imitate the competition and put hard work in hardware. TCP/IP offload NICs (TOE) are becoming increasingly more popular. With RDMA technology layered on top of it you get iWARP. For storage you get iSER (ironically from an IB company!). This technology is being adopted by both the MS and Linux camps so it seems to have a good shot. In fact, many of the interfaces used by IB work about as well over iWARP cards. Things like Message Passing Interface, Direct Access Provider Library, Sockets Direct Protocol (SDP), and iSER do not know the difference between iWARP and IB or anyone else.
Software can just post a full size message and it gets sent out the wire without copying, segmentation, timers, resends, or other CPU hogs. This kind of stuff really helps with large messages. With SDP, apps can be made to take advantage of it without changes to the application. MS is also providing a standard way for just TOE NICs without RDMA abilities to work with the OS. Linux doesn't seem to have a standardized way for TCP/IP to be offloaded entirely but is supporting RDMA and SDP.
The things SCTP seems to offer is more explicit understanding of the difference between failure and congestion and multi-home support. This could make load balancing over multiple paths between hosts pretty interesting. The problem I see is that is that it is competing with the established TCP that now has many of its warts fixed with hardware offload. SCTP will still have the issue of a CPU handling segmentation/reassembly, massive amounts of interrupts, timer/retry overhead, etc. It also seems to have a higher overhead for connection establishment (although that is mitigated by being able to send data during the end phases). Is this a solution looking for a real problem? Pehaps not. Does this really have a chance of being taken up? I am not too confident.
-Ack
-- soldack
The first attempt in the IP world to add a protocol of this type was Reliable Data Protocol, in 1984. (See RFC 908). But that never went anywhere. Since then, nobody has really addressed this. There was ISO TP4, but that didn't go anywhere either, althoug it was fully supported in Windows NT.
SCTP has reasonable congestion behavior, like TCP, so it's an improvement over UDP-based protocols in that regard. Moving some UDP-based protocols to SCTP could be a step up. That's where it could be most useful. It might make sense to put remote procedure call type protocols that now use UDP onto SCTP. If a protocol has to do retransmission, it's better to do it at the transport layer than at the application layer.
The "multihoming" thing seems badly placed, because that's not properly a transport layer function. But I haven't really looked at that.
John Nagle
That's great, as long as you're the only one that uses your network.
What sucks is when some pompous asshat says "no, I can't provide you with a mechanism to accept incoming connections" or "no, you can't open an outgoing ssh connection".
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Multi streaming does not mean multicast. Multi streaming means multiple substreams in one connection. Good for voice trunks (each stream is a voice channel), no benefit for torrents (each connection between two peers usually carries data from only one source.)
Multicast would rock for a P2P distribution system, even "explicit multicast" which has a rather low limit on the number of destinations, as opposed to IP multicast which has no limit on the number of destinations but presents a nightmare for backbone providers. (State must be kept for every multicast group that a particular router handles traffic for.)
retrorocket.o not found, launch anyway?
Unfortunately the current mainline Linux kernel SCTP implementation (LKSCTP) has some serious performance problems. On platforms with mature SCTP implementations (FreeBSD, OpenSolaris), SCTP performs *much* better.
See http://sctp.fh-muenster.de/Performance/index.html
SCTP does have an option for using name resolution to do multihoming, however for practical reasons it is almost universally unimplemented. SCTP multihoming works just fine without it. IP address lists for multihoming are exchanged during the standard connection (association) establishment process.
State cookies are not stored on the server at all, but rather are echoed from the client back to the server as a effective means of SYN flood style DoS attack prevention.
SCTP (properly implemented) is radically superior to TCP for a large class of applications, basically anything that needs low latency reliable message exchange. The lack of message boundary information in TCP causes considerable pain for implementers of upper layer protocols - notably RDMA/RDDP and iSCSI. The running solution for efficient hardware implementation of RDMA and iSCSI over TCP involves *inserting* markers every 512 bytes or so in the middle of a data stream so that the receiver can re-synchronize it efficiently.
The primary SCTP RFC is RFC 2960 for those who are wondering.
You, Sir, are a blatant troll. I happen to know at least one of the developers of SCTP (was one of my professor at university), and Microsoft has nothing to do with this. Stop spreading bullshit.
This sounds somewhat similar to TIPC which we're using in some projects where I work. Like UDP it is message based, but it provides a reliable message transport. It also runs in the kernel as a protocol stack. It does have some differences, though. It is not based on a source and destination, but rather a publish/subscribe mechanism which sounds similar to the SCTP multi-homing support. With the publish/subscribe, one or more clients can indicate that they're interested in a certain service. When that service becomes available or disappears on the node, cluster, or network (depending on the scope of configuration) the client stack will automatically notify it.
It also has the concept of priority in it, so that messages may be prioritized.
Unlike SCTP, however, it does not run on top of IP but is its own protocol that runs directly over the wire, which means that it cannot be routed across an IP network. It is great as an internal embedded messaging protocol, but not as useful when a network is involved.
TIPC is also not connection oriented. There is no connection setup required to send messages much like UDP.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
That's not necessarily fair to MS.
Linux is a very popular platform for researchers to try out new kernel ideas in a real-world system, like networking protocol ideas. This is for a number of reasons (it's well-written, it's easy to hack on, it's open source and doesn't have any weird restrictions, it's free, it's already popular among CS folk, etc.
I'm not familiar with the particulars of SCTP, but just the fact that this is available under Linux (and perhaps that some (all?)) distros make it available by default does not mean that MS is trying to squash the standard. They just have different interests.
Microsoft is a business, and a very conservative one (for the technology industry, at any rate). Unless they have demands from their large corporate customers for a feature, or they think it's going to expand their market, they have little reason to include said feature. It's irrelevant to them whether their own acceptance of something is essential to it catching on -- if you can't make a business case for it, they aren't going to put something into the kernel. That doesn't happen because Microsoft is being particularly antisocial. They're just a business, and they function with certain limitations, as such.
Linux (well, Linus's tree -- I'm sure Novell has their own kernel tree) is built by a bunch of engineers who, as a whole, have no business constraints to worry about. They're interested in making the best technical system possible. Sure, maybe IBM's not going to fund engineers to add Coda support to Linux, but if Linus says "yes, this is technically good", it can go into Linux if someone else wants to write it.
Thus, you have a suit at the highest echelon in one system, and an engineer at the highest echelon (in one tree -- another way in which Linux ensures competition) in the other system.
The case that a libertarian or other hard-core free-markets-no-matter-what advocate would probably make would have is that nobody can have an influential monopoly on the market (not true in this case) and so if someone does something sub-optimal for the customer, they will quickly lose business to the competition.
Now, I don't know whether SCTP is a good idea or not. I'm just pointing out that there are times that having *any* business control the bulk of the market is going to lead to suboptimal handling of consumer interests -- that business need not be Microsoft.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
In a corporate situation, no you wouldn't be a pompous asshat for doing that, you'd just be doing your job.
However if you were an ISP, tasked assumedly with providing connectivity to your customers, and did something similar, then yes, you would be, in my opinion. And there are a fair number of really crummy ISPs who, for one specious reason or another, block various ports and protocols.
And perhaps most unfortunately of all, it's quite common for these ISPs to have regional broadband monopolies, so that a customer doesn't really have the option of just dropping them and switching to a provider that doesn't suck so badly.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
SCTP excels at low latency delivery of small messages. TCP's head of line blocking is a serious problem in many applications. SSH tunneling is a good example.
The main advantage of using SCTP over multiple TCP connections is connection establishment time as well as server overhead. You can create an association with hundreds of streams in the roughly the same time as a single TCP connection, with little or no overhead for unused streams. Then when you want to initiate a new non-blocking transaction you can send a message on a new stream without the three-way handshake of an extra TCP connection.
In addition, a single SCTP socket can handle reliably delivered messages on thousands of streams from hundreds of associations. No need to use select()/poll() on a long list of file descriptors.
I spent last semester taking a class about the nuts and bolts "Upper layer protocols" class with one of the leading SCTP researchers, so I've heard a good bit about this protocol. It's quite good, better than TCP in almost every respect. The one problem is (as you probably guessed) overcoming the fact that TCP is ubiquitous and has a gigantic code base.
So I asked - why not have an API for translating TCP calls into SCTP? He told me that this is called a "shim" and that one already exists. He also said the primary area of interest regarding the shim was getting the shim working on windows and deployed by default with windows. That would significantly reduce the gap.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
They will merge in the stuff from the gaim-vv fork in the release AFTER 2.0.0, so we have 2 versions to go before we can video conference on Gaim.
The article makes no mention of congestion avoidance. Does SCTP use AIMD like TCP? Is it TCP-friendly?
How is this flamebait? Also no, not really.
Interestingly, I had just run across these yesterday--note these used OpenSS7 implementation and call out issues w/LKSCTP mentioned in other posts:
u ments/DOA2003_97_Thaker.pdf
3 _Manual/Presentations/5-4_Thaker_etal.pdf
http://www.atl.external.lmco.com/projects/QoS/doc
Seems the funding for the TAO SCIOP implmementation came from the US Navy:
http://www.omg.org/news/meetings/workshops/RT_200
Matt
SCTP and Infiniband focus on different areas. IB is largely a high performance HPC / cluster network architecture for LAN applications, where SCTP is a transport protocol designed to operate efficiently under WAN conditions (significant packet loss, high RTTs).
SCTP is a more efficient RDMA/iWARP transport than TCP, but the differential advantage of SCTP over TCP is much lower in a LAN environment due to the low RTTs, so RDDP/TCP dominates so far despite the bizarre marker insertion scheme (MPA). Same goes for iSCSI.
The interrupt issue has largely been solved - on Linux NAPI dynamically switches between interrupt and polled mode to reduce this overhead to negligible levels. Message signalled interrupts also help considerably.
What would be much more helpful (and economical) for iSCSI, SCTP, and RDDP is NIC CRC32C checksum generation. CRC generation is quite expensive in software but trivial in hardware.
SCTP wasn't originally designed for load balancing a single association via simultaneous multi-path transfer (SMT). It can be done, but it requires some loss detection algorithm changes. Someone still needs to develop a option to coordinate this at association establishment time.
One advantage of SCTP over TCP is that on a per stream basis, SCTP connection establishment overhead is much lower than TCP - basically O(1) instead of O(N) in the number of streams.
Layer 3 multihoming doesn't scale due to the combinatorial explosion of routing table entries. This problem is sufficiently serious that there is an IETF working group dedicated to providing a shim layer between layer 3 and layer 4 for IPv6 so that the problem with the size of global IPv4 routing tables does not repeat with IPv6.
Even now, it is practically impossible for a small to medium size business to be multihomed at the network layer, because they can't get an IP address block large enough so that BGP re-routing works across multiple providers (without being filtered away). And of course managing BGP sessions with multiple providers is time consuming, if you can get them to do it at all.
Both the proposed shim6 layer and SCTP provide solutions to the multihoming problem that have a much lower failover time, and much lower overhead than using BGP to do it. The providers neither need to know nor care.
And of course the advantage of SCTP / shim6 over using DNS to do it is that they both fail over active connections, not just retry new ones with different addresses.
The denial-of-service attack will not work if the attacker uses forged source addresses, as is common with TCP.
This and egress filtering are why a lot of script kiddies don't use forged source addresses in their DOS attacks anymore. Instead, they use completely valid requests from a network of 100,000 compromised Windows XP Home Edition machines that are otherwise used for running poorly written yet popular software that requires administrative privileges.
Congestion control is an area where SCTP is much like TCP. SCTP uses AIMD on a per destination address basis. However any of the the alternative congestion algorithms for TCP would behave similarly with SCTP.
Of course given the additional message boundary information available in SCTP, further improvements could be made.
Any reasonable app can wrap up similar functions in a well-written messaging library. There may be some minimal enhancements by performing certain operations in the kernel (and hopefully in hardware), but the main stuff can be handled in any reasonable message-oriented transmission kit (bit torrent, jabber, and libraries I have written). The key here: messages good, streams bad. If you take that concept to heart you can avoid a lot of headaches (scaling, repairing, multi-pathing, multiplexing, guaranteed delivery, etc.).
----- Refactoring is the reason why man does not mistake himself for a god.
Somehow I think Van Jacobsen would disagree with you...
See http://lwn.net/Articles/169961/
In fact the Linux TCP stack does most of its processing in process context by default (using VJ style prequeuing), although there is an option to change this for latency sensitive workloads.
This concept has potential but there are some problems. First, SCTP does not support half open connections like TCP, so some applications will not work without modifications.
Second, trying SCTP first and then falling back to TCP later causes considerable delay. To fix that problem the shim would need to insert itself in the name resolution process (getnameinfo) so that it could intelligently decide which protocol to try first. Of course name servers would have to carry SRV extension records to indicate that SCTP was supported on a port / ULP basis.
From Wiki:
Chunks
Each SCTP packet consists, in addition to the common header, of chunks. Each chunk has a common format but the contents can vary. One chunk is display in the diagram to the right with the green background.
Chunk type
An 8-bit value predefined by the IETF to identify the contents of the chunk value field.
Chunk flags
Eight flag bits whose definition vary with the chunk type. The default value is zero.
Chunk length
A 16-bit unsigned value specifying the total length of the chunk in bytes (excludes any padding) that includes chunk type, flags, length, and value fields.
Data can be sent on the third leg of SCTP's four-way handshake, bundled with the COOKIE ECHO, making establishment time just as fast as TCP's three way handshake. The fourth leg (COOKIE ACK) is just to tell the client that the server received and accepted the COOKIE ECHO.
So instead of:
1. SYN
2. SYN ACK
3. REQUEST DATA
4. RESPONSE DATA
you get:
1. INIT
2. INIT ACK
3. COOKIE ECHO + REQUEST DATA
4. COOKIE ACK + RESPONSE DATA
Same overall latency, better security.
Most modern NICs can offload TCP checksum generation and checking. Many can offload send side TCP segmentation (aka TSO / LSO / Large Send support).
However full TCP offload engines are expensive and rare outside of hardware iSCSI and RDMA implementations. They may be worthwhile at 10 Gbit/sec, but modern software TCP stacks handle 1 Gbit/sec with neglible overhead on decent hardware.
The multi-streaming solves a nasty gotcha with forwarding multiple traffic over a single ssh connection: one stalled forwarded connection brings the entire show to a dead stop.
Some of the protocols that could benefit from SCTP include:
now we need to go OSS in diesel cars
Not that this recurring, stupid, flamebait, anonymous post actually warrants a response, but I felt inclined. Being employed as home computer technical support for many years, I've had contact with many many varied people and their computers, across three states and working in five major metropolitan areas.
The majority of homosexuals that I've worked for use Macs. None have used Linux. Something about their sense of style I guess, Macs are counter-culture and stylish, Linux is counter-culture and... geekish.
And no, I'm not saying all Mac users are "fags", just that most "fags" prefer Macs. Linux is for geeks. Get your facts straight. (For the record, I prefer Linux, making me a geek, not a fag, and not a homophobe, either)
SCTP sounds like a kitchen sink solution; it has some nice features and some useless features.
For example, manually opening multiple connections through different interfaces and then having the SCTP implementation figure out which one to send through is nonsense; if the system has multiple routes to the Internet, then that can be taken care of at the IP level.
Similarly, preservation of write boundaries is a useless gimmick that is rarely needed, and when it is needed, can be easily implemented in user code.
The four-way handshake during setup is possibly useful, but you can trivially get the same with TCP in a backwards compatible fashion if you configure your kernel to protect against SYN spoofing.
Altogether, I'm not quite sure what problem SCTP is supposed to solve. SCTP has made its way into some other standards, so it will probably be unavoidable, but it's not a well-designed protocol in my opinion.
Okay, I'll bite -- why? (I'll assume you aren't just being tautological and defining any non-buggy multithreaded program as "trivial"!)
No, it's not a tautological statement. And, actually, it's probably too strong (120 characters isn't much to say something in). It's a statement about engineering, not about computer science. Futhermore, I was thinking of systems without "hard" priority levels -- RTOSes have legitimate reasons for use of hard priority level threading. However, this is not the case for almost all multithreaded Windows software out there. There probably do exist some preemptively multithreaded systems out there that are written correctly. However, it's far less in the "too strong" realm than most people would probably buy at first.
I've found that preemptively multithreaded systems seem to very, very commonly have synchronization problems. This is due to a number of factors:
1) Writing multithreaded software correctly requires solid knowledge of multithreaded design. This is not something that you can simply pick up a book and learn or take a class and be guaranteed that ability at the end -- it requires a very different way of thinking. I have worked with very experienced engineers (quite competent ones) who have produced designs that they were *certain* were right...only to have scads of synchronization problems turned up. I am amazed by the number of people who fully believe that they understand how to design and implement threaded code and yet cannot produce solid designs. It is a simply overwhelming number. I have yet to meet the person who I would trust to write a multithreaded system that I would trust my life to. I am willing to believe that such a person exists; however, they are dwarfed by the hordes of people who believe that they can properly design multithreaded systems but simply fail to do so (and worse, do not understand that they have failed to do so).
2) Synchronization problems are very easy to introduce, but very difficult for someone else to find while examing the system. If an engineer makes a typing error, we have statically-typed language compilers that can catch the error. We do not have (at least widespread, and in the mainstream) tools for so statically identifying threading errors.
It very easy to use threads incorrectly and hard to use them correctly -- it's easy to say "oh, I won't synchronize this here, and I'll go back and handle it later if we use this for anything other than my current hack", because writing a correct threaded system may require significant changes to existing synchronization design.
Basically, the failure mode for threads is bad compared to most other language features -- it takes effort to correctly design a threaded system, and the result of a misdesigned system is often a very difficult to produce bug that comes up unexpectedly and can cause a wide range of problems. Contrast this with a single-threaded event-driven program -- if a mistake regarding interaction with other tasks is made here, it will probably manifest itself as taking too long to complete a particular chunk of work. The problem is generally easy to localize, and it is generally easier to reproduce.
3) Many synchronization problems with preemptively multithreaded code are essentially impossible to catch with routine testing; their failure rate is very low. Furthermore, even (expensive) full-coverage testing does not necessarily expose synchronization problems.
4) While this is not an inherent reason for failure, it is a reason why threads are overused. Threads "demo" well -- disproportionately better than they perform in the real world. For a language feature to be widely accepted, it is important to be able to produce a trivial example where code using the feature greatly benefits. It is possible to create a trivial threaded example where a thread operates in complete isolation from the rest of the system (the sort of thing that a Unix programmer would use multiple processes for). The problem is that th
Any program relying on (nontrivial) preemptive multithreading will be buggy.
True, but then again, I am a fag...
SCTP has a feature that lets us set fuzzy levels of reliability based on application needs i.e. a connection will time out after a certain time. This feature however is not fully implemented and if it can be provided for each logical connection then only and then can it be a truly integrated TCP-UDP solution.
Actually, most iWARP/RDMA stuff doesn't have a software interface to TCP at all - the hardware handles not only TCP, but three or more layers on top of it (at least MPA, DDP, and RDMA, plus iSCSI in some cases). That type of interface is not a problem. What is controversial is using TOE for conventional TCP applications using kernel space dispatch.
This is a bit of an end run around the Linux kernel bridging, routing, and filtering layers, which is the primary reason why support for it won't get merged in the kernel socket layer until RNICs can at a minimum do IPtables like IP address filtering and proper dispatch so that some packets can be routed through the kernel layers on an Ethertype and IP protocol / address / port specific basis.
A typical SCTP socket implementation has four logical layers:
1. Socket
2. Stream
3. Association
4. Path
SCTP sockets come in two varieties, one-to-one style and one-to-many style. The one-to-one style handles up to 64K streams in each direction between two endpoints.
The one-to-many style aggregates several associations on the same endpoint, presenting a socket interface that resembles that provided by UDP, except reliable and ordered. The primary difference with RDS is that SCTP is generally implemented completely in software. An SCTP stream pair is logically equivalent to an Infiniband QP, but if someone wanted to provide a high performance SCTP style interface over IB they would likely run out of hardware QPs with that kind of mapping. SCTP associations with thousands of streams are common in the telco world.
RDS works fine with association level QPs because packet loss and high RTTs are not much of an issue with IB. I believe it has strong ordering guarantees making independently ordered streams moot. Mapping SCTP streams to QPs would be ideal for MPI / RDMA style applications, however.
(PR)SCTP's timed reliability service is on a per message basis. You just set the sinfo_timetolive for a message in milliseconds, and the message auto-expires if it hasen't been completely transmitted before that amount of time has elapsed. See RFC3758 for details.
Association timeout (SCTP_AUTOCLOSE option) is something else entirely, normally used to make UDP style applications transparent to association setup and teardown.
So then, how does that explain montspace.com, a very important icon in the Linux community?
*shrug* you can believe what you wan't, but in the end when Microsoft change tack mid stream don't come running to me for support.
Several people have accused you of trolling. I think that's incredibly unfair. A quick glance at your posting history would have been sufficient to convince anyone that you simply don't have the intellectual capacity for trolling.
Every single person who has accused you of trolling should apologise right now for the lazy assumption that you are anything other than a slack jawed, drooling retard who lacks the skills needed to annoy people on purpose.
I can only apologise on behalf of Slashdot for misrepresenting you so badly. I just pray this incident doesn't put you off posting again. Your carers believe that it is a much more positive activity for you than licking windows and we would hate to impede your development.
Btw, read my my last 3 blog entries about some Linux problems: my blog
I hope you don't mind, but I'm just reposting part of your blog here, as I think it deserves a wider audience.
The way I see things, Linux has much to learn and improve. It can be secure and fast, it is and and I never told you it weren't in this whole article! The problem is that people mix the words and concepts, Linux=The Kernel and that is fast and secure, Linux Software=THE PROBLEM. Yet, my opinion (shared with some friends) is that even the kernel is becoming obsolete and its not envolving to the Desktop as Linus promissed for 2.7. And without proper software and standarts that could kill and fire a lot of people...
I see Mono as a performance boost, security boost and standartization boost in Linux world. We only need to learn by the past mistaques and try to fix them, then more and more people will help and use.
Ladies and gentleman, there is no point in trolling anymore. The art has been perfected. You will never better what alexmepigo has acheived here. Linux needs to switch to Mono now or people will die! Linux is slow because it doesn't use enough Mono and Java! Seriously people, alexmepigo has taken things to the next level and left you in the dust. He's even perfected the whole "I donta speeka very good Eeeeenglish" thing.
I thought it was very reminiscent of some of Trollaxor's finest work. Go check out alexmepigo's blog - there's much more quality material where that came from.
It's *Linux* that is driving ther adoption !
For the record, Solaris 10 has a built in SCTP stack too...
http://blog.nexusuk.org
Last time I looked seriously at SCTP (18 months ago), it had two "problems" with multi-homing and failover.
1) It only sends traffic over the current primary connection. Because the standby connection(s) are idle, it cannot detect failure on them until it needs to use them. On IP networks, failure takes a long time to detect. If the primary connection fails, it could switch to another failed (but not detected as failed) connection when there is a (better) working alternative.
2) It does not load-share. If there are three diverse routes, it makes sense to share the load over all three. This requires some metrics: Two broadband routes would loadshare, but in a broadband and ISDN backup case, the sharing would need to be uneven, or not at all (i.e. main+standby configuration).
Interestingly, providing 2 would solve 1.
Of course, these are problems introduced by the ability of SCTP to multi-home, it is not a regression on TCP (or UDP).
Yhee, so I write bad english, so what? I'm not English am I?
Those 3 articles are my opinion about specific problems we face in Linux and I talk about how Mono can help solve then, if you read the entire article you'll know that the piece you posted here has no meaning because you don't place it in the right context.
I hope some moderator just call you a TROLL.
Saven: MS does not really have anything to do with SCTP. In fact they have refused to even consider implementing it (yet), until they have a business need. They were not part of its development nor are they interested in implementing it AFAIKT. It would be very hard for MS to do anything to SCTP at this point. Oh, they could in theory define their own chunk types that do special things and not tell us what they are.. but they still will have to inter-operate with the base protocol.. Of course that is assuming they ever get their act together and build an SCTP version. Its actually rather interesting since it is possible that they will finally find the business need and then have to try to rush to market with a stack... which will put them at a serious performance dis-advantage... after all look at lk-sctp its at least 5 years old and it still has not been fully performance tweaked yet... Of course MS has never been shy about shipping something that blue screens every few hours :-D
It takes time to develop a stable, reliable, good
performing, transport stack.. and when SCTP
finally hits MS it may hit them over the head :-D
R
There is a simple solution to the software integration problems described in your paper: stream sockets - sockets that handle one stream (pair) of an SCTP association at a time, more like a traditional TCP socket.
One a web browser like Firefox, whenever a new connection to the same server is going to be established, just peel off a new stream socket. Then there is no problem with rendering threads processing one stream at a time.
On the web server side, accept() can be made to deliver new stream sockets when the first request arrives on a stream, so that each worker thread handles one stream at a time.
That would allow Firefox, Apache, etc. to support SCTP multi-streaming with minimal changes.