Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Better Networking with SCTP

ScuttleMonkey posted more than 8 years ago | from the viva-la-sctp dept.

233

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."

cancel ×

233 comments

Sorry! There are no comments related to the filter you selected.

How long... (2, Interesting)

Elitist_Phoenix (808424) | more than 8 years ago | (#14853239)

How long do you think it will be before this is adopted into the mainstream?

Re:How long... (4, Funny)

Rosco P. Coltrane (209368) | more than 8 years ago | (#14853243)

How long do you think it will be before this is adopted into the mainstream?

Easy that: as long as it took IPv6 to be adopted into the mainstream.

Re:How long... (4, Informative)

sjames (1099) | more than 8 years ago | (#14853320)

Easy that: as long as it took IPv6 to be adopted into the mainstream.

Probably not that long. The problem with IPv6 is that too many entities are involved in a successful v6 deployment and too many changes have to happen at different levels.

OTOH, SCTP requires only a client and a server that want to use it.

Re:How long... (4, Insightful)

KiloByte (825081) | more than 8 years ago | (#14853348)

OTOH, SCTP requires only a client and a server that want to use it.

And no overzealous firewalls on the way.

Re:How long... (1)

ROOK*CA (703602) | more than 8 years ago | (#14853493)

And no overzealous firewalls on the way.

Guess I must have "underzealous" firewalls, since they allow the traffic I tell them to and block everything else. ;)

Overzealous security admins (1)

typical (886006) | more than 8 years ago | (#14853774)

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".

Re:Overzealous security admins (2, Insightful)

ROOK*CA (703602) | more than 8 years ago | (#14853861)

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".


I feel your pain, however I've found that it makes sense use a simple formula when evaluating an end user request to allow XYZ traffic to traverse a firewall(s) on my organizations network, 1. Is there a business need for it or is it just a user saying "oh this would be nice to have" 2. Is there a more secure and/or functional way to accomplish what the user needs to do? 3. Am I going to open up my network to significant security risks if I do this? do those risks outweigh the business need?

Characterizing any admin that says to you "no you can't traverse the company firewalls with XYZ traffic because doing so represents a significant security risk to the company network" as a "pompous asshat" is a bit unfair don't you think? perhaps you should attempt to look at it from the "pompous asshats" point of view and ponder what your response would be if the positions were reversed, if your answer is "well I'd let any traffic that any user asks for to traverse my firewalls" then there's a very good reason you're not the one making the determination what crosses company firewalls. ;)

No, but if you were an ISP... (2, Insightful)

Kadin2048 (468275) | more than 8 years ago | (#14853952)

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.

Re:No, but if you were an ISP... (1)

ROOK*CA (703602) | more than 8 years ago | (#14854003)

I completely agree with the situation that you describe, any ISP that tells it's customers "no you can't use XYZ protocol on our network" (especially in the case of outbound connections), is indeed a pompous asshat. I would say there is a valid arguement for not allowing inbound service ports like HTTP, SMTP, etc.., to customers that are *residential* customers but, not allowing outbound SSH is just well ....evil not to mention lame.

Re:Overzealous security admins (1)

Jeremi (14640) | more than 8 years ago | (#14853989)

Any program relying on (nontrivial) preemptive multithreading will be buggy.


Okay, I'll bite -- why? (I'll assume you aren't just being tautological and defining any non-buggy multithreaded program as "trivial"!)

Re:How long... (1)

sjames (1099) | more than 8 years ago | (#14853963)

And no overzealous firewalls on the way.

Compared to your chances of convincing an ISP to upgrade their routers and buy a prefix from ARIN, getting the firewall fixed is child's play even if the admin wears a huge tinfoil napolean hat and hides behind 'the commitee'

Re:How long... (1)

DrSkwid (118965) | more than 8 years ago | (#14853882)

That's not the problem.

The problem with IP6 is that it isn't backwards compatible with IPv4.

IPv6 will *never* happen.

http://cr.yp.to/djbdns/ipv6mess.html [cr.yp.to]

Re:How long... (5, Informative)

Ulrich Hobelmann (861309) | more than 8 years ago | (#14853356)

That's because IPv6 is *IP*. SCTP builds on top of IP (v4 if you want), just like UDP and TCP.

Just like many applications (mostly streaming servers and games, I suppose) use UDP without anybody caring, you can use SCTP without any host between client and server caring.

It's something for applications to use, not something that requires a different internet infrastructure, replacing routers, software etc. (IPv6 address syntax is different from the v4 one...).

Re:How long... (2, Interesting)

Neo-Rio-101 (700494) | more than 8 years ago | (#14853387)

As soon as bittorrent gets vastly imporved from it's ability to multi stream data.

Obvious implementation of the protocol, really.

Unfortunately (1)

Andy Dodd (701) | more than 8 years ago | (#14853807)

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.)

Re:How long... (4, Interesting)

canuck57 (662392) | more than 8 years ago | (#14853454)

How long do you think it will be before this is adopted into the mainstream?

Probably never main stream. Maybe for some telco types in niche applications... but it is too easy for 99% of the world to just open 2 sockets if you want 2 streams, or rpc's and threads... both of which are well supported and seasoned. Sctp is new, new bugs, not supported everywhere and as a result will go not go far.

One might argue it is supposed to be more secure, I argue it is not. If it was it would be tied to kerberos and ipsec and use AES at the transport layer.

Sctp has only one advantage, and this too could be done using TCP or UDP with not too much effort. That is you can open one socket and have mutiple streams inside, reducing the socket count on servers, a problem if you are routing more than 48000 calls or so. But yor could also do this with "TCP connecting pooling", a common way around this issue.

But like ATM, it is the telco business push. ATM anyone?

Sctp to me looks like a problem looking for a home for 99% of us. But at least an informative post so when I see the compile option I will turn it off.

Re:How long... (2, Informative)

zm (257549) | more than 8 years ago | (#14853532)

> Sctp is new

Nope. I worked on SCTP implementation in year 2000.... Nortel had it in 1999.

zm

Re:How long... (5, Interesting)

canuck57 (662392) | more than 8 years ago | (#14853660)

Nope. I worked on SCTP implementation in year 2000.... Nortel had it in 1999.

New as in it is just making it into some kernels. And it most of us have never seen an application use it. And it may be years before we do. However, as stated it exists in a niche telco market.

Nortel (used to work there) and the industry still has the "central office" mentality. Nortel had one thing right, VoIP is the future. What the telco business as a whole has wrong is how this will be done.

In the future there will no need for a central office, all calls will NOT route through central servers and thus negate a heavy need for sctp altogether! sctp is like a T1-T2-Txxx to sockets, allowing n channels of calls through one IP connection. If VoIP (not strictly defined) goes point to point direct there is no need for a central office. End user devices only need 1 to 4 channels. (Audio/Video/Control/MP3 Movies).

What will happen is someone like Linksys (or a Chinese company) will get enough momentum to produce a $99 device you hook to your internet, some LDAP server out there will be your directory and call routing will go direct device to device over TCP/IP. The MOBILE protocol has a better chance of surpasing SCTP as being in common use. You might even run call conferencing right off your own device.

Central office technology has seen it's peek hayday. SS7, BSSMAP, ISDN, SONET and others are far too complex, expensive, patented and cumbersome - and will be religated to legacy wireline only. SCTP might be used in this niche area to concentrator like a RLCM to wireline services. Hardly end user equipment.

The Internet is slowly eatting the telco business alive. As the traditional telco business market is evaporating.

Wireline needs to quite the bickering, quite tripping on DCLEC cables and get decent inexpensive DSL services or they can say good-bye to their business. DSL is the only hope for the wireline side of the telco business and most are screwing it up big time.

Cisco, if they keep innovation going high are going to put Nortel out of business. Central offices are being replaced with Network Access Point (NAP) and Cisco is king. Nortel might be best to spend their efforts on making the biggest, fastest, cheapest internet router possible. A DMS10000, 10000 as it can take 10000 IP based fibers.

BTW, I loved working for Nortel, but left as I was a grossly underpaid Canadian and could see Stern was going to wreck the company.

Re:How long... (1)

marcosdumay (620877) | more than 8 years ago | (#14853723)

"Sctp is new, new bugs, not supported everywhere and as a result will go not go far."

Oh, so anything new goes nowhere. I can see your point, we are still trying to make those things as fire and the well mainstream...

Re:How long... (1)

endoplasmicMessenger (883247) | more than 8 years ago | (#14853996)

Probably never main stream. ... it is too easy for 99% of the world to just open 2 sockets

Or you could use JSCTP [sourceforge.net] , which is just as easy as openining two sockets.

Goodbye TCP? (3, Insightful)

BadAnalogyGuy (945258) | more than 8 years ago | (#14853247)

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?

INIT floods (1, Interesting)

gordonb (720772) | more than 8 years ago | (#14853311)

From the article:

The problem that can occur with TCP is when a rogue client forges an IP packet with a bogus source address, then floods a server with TCP SYN packets. The server allocates resources for the connections upon receipt of the SYN, then under a flood of SYN packets, eventually runs out and is unable to service new requests. This is called a Denial of Service (DoS) attack.

SCTP protects against this type of attack through a four-way handshake and the introduction of a cookie. In SCTP, a client initiates a connection with an INIT packet. The server responds with an INIT-ACK, which includes the cookie (a unique context identifying this proposed connection).

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.

Re:INIT floods (4, Insightful)

KiloByte (825081) | more than 8 years ago | (#14853342)

Wrong. A connection with a forged source address won't take any more resources than a single incoming packet, a single outgoing packet and the CPU cost of computing a cookie. That's all.

Flooding using the flooder's true address will still work, but it is trivial to block. Sure, having 100000 zombies flood a single destination will put quite a burden and will force the floodee to maintain a huge list of banned addresses, but, a single hash table on the router will alleviate anything except for bandwidth wasted.
This is same as a full TCP connect() flood.

There is a TCP hack named "syn cookies", but this doesn't work very well as TCP wasn't designed to be resistant to SYN floods.

Re:INIT floods (4, Informative)

Jonner (189691) | more than 8 years ago | (#14853343)

Read about SYN Cookies [cr.yp.to] . This is a method of avoiding SYN DOS attacks that has already been implemented in Linux (and probably elsewhere) for a while. I think SCTP just integrates the same concept into the official protocol specification. Once the SCTP server sends the INIT-ACK, it doesn't have to keep track of that association until the client sends a COOKIE-ECHO.

Re:INIT floods (5, Insightful)

lagfest (959022) | more than 8 years ago | (#14853364)

lets change the quote scope a little:

SCTP protects against this type of attack through a four-way handshake and the introduction of a cookie. In SCTP, a client initiates a connection with an INIT packet. The server responds with an INIT-ACK, which includes the cookie (a unique context identifying this proposed connection). The client then responds with a COOKIE-ECHO, which contains the cookie sent by the server. At this point, the server allocates the resource for the connection and acknowledges this by sending a COOKIE-ACK to the client.

Funny how things suddenly makes sense when you read the entire paragraph.

Re:INIT floods (1)

lemonjelo (157554) | more than 8 years ago | (#14853502)

So what is it about tracking unique contexts via cookie that is less prone to abuse than tracking half-open connections on the server?

Re:INIT floods (5, Informative)

lagfest (959022) | more than 8 years ago | (#14853591)

Who says you have to track the cookies? Just make a hash of the client's ip address, port, and a key that changes every 20 seconds. Now you only have to save a history of the three latest keys.

In fact, that's pretty close to how it's done according to SCTP for beginners [uni-essen.de]
The server receives an association setup request (an INIT chunk) usually in the CLOSED state, and analyzes the data contained in that chunk. From that it generates all the values needed at its side to enter an established association, and generates a secure hash of these values and a secret key (e.g. with the MD5 or SHA-1 algorithms). The values are then put into the so-called COOKIE, along with the derived message authentication code (MAC). This COOKIE is returned to the sender of the INIT chunk in an INIT-ACK chunk. The server remains in the CLOSED state, and forgets all about the received INIT chunk.

Re:INIT floods (1)

lemonjelo (157554) | more than 8 years ago | (#14853624)

wish I could mod that up

That's along the lines of what I assumed, but didn't see it in the article and it wasn't clear in the paragraph quoted. Thanks!

Re:INIT floods (0, Offtopic)

Tim C (15259) | more than 8 years ago | (#14853661)

This is totally off-topic, but in response to your analogy, surely the levees being overtopped would have resulted in a lot less water and therefore much-reduced flooding? I'm no fan of Bush, but it seems logical to me to worry less about over-flowing than an outright breach (but then, I'm also not a hydro-engineer).

No (0)

Anonymous Coward | more than 8 years ago | (#14853315)

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.

Re:No (1)

tajribah (523654) | more than 8 years ago | (#14853361)

Well, such arguments don't say much – everything you can do over IP, you can do over UDP. You can implement SCTP over UDP, as well as you can do TCP over UDP. However, that doesn't mean it makes sense to do so :)

People are already doing similar things over UDP for years and in the vast majority of cases they get it wrong (poor performance, broken congestion avoidance algorithms and so on). That seems to suggest that the problem is not so trivial as it looks and that it makes sense to finally find a good solution and standardize it.

RTFP (0)

Anonymous Coward | more than 8 years ago | (#14853416)

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.

Re:Goodbye TCP? (3, Insightful)

Jonner (189691) | more than 8 years ago | (#14853327)

It sounds to me like SCTP was designed to allow the same capabilities as both TCP and UDP within the same protocol. The designers had the benefit of seeing the advantages and disadvantages of both protocols over the many years of application implementation. Using SCTP won't necessarily make any particular application better than it could be done with either TCP or UDP or a combination of two, but it will probably make the implementation simpler and easier, especially when you would otherwise need to use both TCP and UDP in the same application or when you need failover.

Totally Feakin Awsome. (0)

Anonymous Coward | more than 8 years ago | (#14853443)

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!

Re:Goodbye TCP? (1)

canuck57 (662392) | more than 8 years ago | (#14853473)

not susceptible to SYN floods like TCP

Init and cookie floods instead, the basic problem still exists.

Re:Goodbye TCP? (2, Informative)

KDR_11k (778916) | more than 8 years ago | (#14853649)

The SYN flood happens because the server has to keep track of the connection until it times out and there's a limit to the number of connections the server can keep track of, with the cookie method the server gets an INIT, sends out the cookie and forgets about the connection. Only when that is returned the server opens a connection. Sure, you could go through the proper protocol for starting the connection but that forces you to tell the server the real IP of your DoSing client instead of putting a number of fake IPs in there. The server could just start ignoring your client for a while and your DoS has failed.

Re:Goodbye TCP? (1)

skayell (921119) | more than 8 years ago | (#14853550)

Maybe if someone would CLEARLY delineate the specific problems this protocol is meant to address and then explain exactly what the benefit is, instead of just doing a lot of comparisons without a benefit analysis, non-geeks like myself could get the gist of what they're trying to say.

Disclaimer: I'm not a geek, but some of my best friends (and relatives) are.

Re:Goodbye TCP? (0)

Anonymous Coward | more than 8 years ago | (#14853634)

someone's been watching Dangermouse.

What's not said (-1, Flamebait)

Saven Marek (739395) | more than 8 years ago | (#14853254)

What's not said is this is a MS derived "standard" that is not open and will probably be changed and not documented by MS as soon as it becomes to their advantage to do so :thumbsdown:

Credit where due (0)

msobkow (48369) | more than 8 years ago | (#14853262)

While the protocol was originally designed for telephony signaling...

In other words, it started out in the hands of AT&T, Bell Labs, Northern Telecom, Alcatel, et. al.

Re:Credit where due (1)

Saven Marek (739395) | more than 8 years ago | (#14853267)

> it started out in the hands of AT&T, Bell Labs, Northern Telecom, Alcatel, et. al.

Both are also monopolists if you might notice.

Re:Credit where due (2, Informative)

tpgp (48001) | more than 8 years ago | (#14853406)

While the protocol was originally designed for telephony signaling...
In other words, it started out in the hands of AT&T, Bell Labs, Northern Telecom, Alcatel, et. al.

Utterly incorrect.

If you had only taken ten seconds to check wikipedia's sctp page [wikipedia.org] you would have found it was developed by the Internet Engineering Taskforce's SIGNTRAN [wikipedia.org] working group.

The IETF is an open, all-volunteer standards organization and couldn't be further in spirit from the monopolies you mention.

Give credit where it is due indeed.

(oh and this protocol was defined in 2000 - far later then the telephone signalling I suspect you're thinking of)

Re:Credit where due (0)

Anonymous Coward | more than 8 years ago | (#14853435)

Telcos are greedy bastards, so who gives a fuck. Now mod this insightful.

Re:Credit where due (0)

Anonymous Coward | more than 8 years ago | (#14853601)

From the RFC:

Network Working Group L. Ong Request for Comments: 3286 Ciena Corporation Category: Informational J. Yoakum Nortel Networks May 2002. Nortel and Ciena are responsible; sorry about the poor formating; junk filter has gotten in the way.

Just has to be said; check out SS7; there is a lot to learn that could be applied to the world of switching and routing.

Re:What's not said (3, Informative)

jhermans (108300) | more than 8 years ago | (#14853368)

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.

Re:What's not said (-1, Troll)

Saven Marek (739395) | more than 8 years ago | (#14853373)

*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.

Re:What's not said (1, Flamebait)

Cal Paterson (881180) | more than 8 years ago | (#14853572)

What the fuck are you on about? SCTP has nothing to do with microsoft, jackass.

Re:What's not said (1, Informative)

Anonymous Coward | more than 8 years ago | (#14853928)

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.

Re:What's not said (1)

gbickford (652870) | more than 8 years ago | (#14853858)

"The current version is sctplib-1.0.4, published on September 16th, 2005. Please note that this is a prototype implementation. This version should run on Linux, FreeBSD, Mac OS X, Solaris and Windows."
http://www.sctp.de/sctp-download.html [www.sctp.de]

Linux is a popular research platform (2, Interesting)

typical (886006) | more than 8 years ago | (#14853951)

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.

multihoming? (2, Interesting)

Loconut1389 (455297) | more than 8 years ago | (#14853256)

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?

Re:multihoming? (1, Redundant)

Jonner (189691) | more than 8 years ago | (#14853310)

Yes, I think you did miss something. Why would hearbeat require a bigger routing table? Perhaps you're confusing multi-homing with multicasting. And who's this Youd character?

Re:multihoming? (5, Informative)

isj (453011) | more than 8 years ago | (#14853312)

I don't know if you missed something - I didn't RTFA.

Heartbeats are optional. Some real-time applications probably want to use heartbeats every 10 seconds, while other can disable them completely.

The multihoming has nothing to do with routing table size. The multihoming feature is used for providing better connectivity.
Imagine your laptop with WiFi. If the application (say, FTP download) used SCTP instead of TCP then the download would not break when your laptop moves from one access point to another and switches ip-address. SCTP survives that.

Re:multihoming? (1)

TemporalBeing (803363) | more than 8 years ago | (#14853906)

The multihoming has nothing to do with routing table size. The multihoming feature is used for providing better connectivity. Imagine your laptop with WiFi. If the application (say, FTP download) used SCTP instead of TCP then the download would not break when your laptop moves from one access point to another and switches ip-address. SCTP survives that.

It would only survive it if both networks were simultaneously connected. If, however, you were only connected to one network at a time, it would still fail if that network connection (e.g. satellite) failed.

It might be a little more resilient in that it has automatic routing built-in to switch to another network segment, but if there is no other network segment, it will still fail.

Re:multihoming? (5, Informative)

romiz (757548) | more than 8 years ago | (#14853367)

Did I miss something?

This is an transport layer, not a network layer. It is only necessary in endpoints, such as clients and servers, and it might be a good thing if firewalls understood it. But the routers don't interpret it, so there won't be any change on backbones, except a slight increase in traffic with a few more keep-alive packets.

Re:multihoming? (1)

The Cisco Kid (31490) | more than 8 years ago | (#14853567)

The 'multihoming' they are referring to is an entirely different beast than the 'BGP multihoming' you are thinking of. They are just talking about when a box has two interfaces, each with a different IP address. TCP forces a connection to be bound to a specific interface, this SCTP doesnt. There are no changes to the network IP routing functions. (The remote end sends to the other IP, the network doesnt route the first IP to the second network)

Its an unfortunate re-use of the same term.

WOW! (3, Funny)

jav1231 (539129) | more than 8 years ago | (#14853314)

Second City Transport Protocol!? John Candy would be proud!

Re:WOW! (0)

Anonymous Coward | more than 8 years ago | (#14853547)

So where are the DRM features, and the link with trusted computing and remote attestation?

I know, I know, this may well be a fine new protocol without any ulterior motive behind its design... but I'm getting used to "new" protocols turning out to be old protocols that have been crippled and broken with DRM features. So I had to ask.

Cool thing (1)

Ulrich Hobelmann (861309) | more than 8 years ago | (#14853346)

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.

Re:Cool thing (2, Insightful)

autOmato (446950) | more than 8 years ago | (#14853410)

This is what I always wanted, but never had the time or resources to develop...

What for? Could you give a specific example of an application where such a protocol would be needed? (That is where using TCP or UDP would require a severe overhead in the application layer.)

If you have always wanted such a protocol, you certainly must have had a specific use in mind.

Re:Cool thing (1)

Ulrich Hobelmann (861309) | more than 8 years ago | (#14853498)

Well, as they mention, TCP is stream-based, so if you want to transmit message chunks, something more like UDP is cool. OTOH, UDP isn't safe, so you'd have to implement half of TCP anyway (re-transmit, maybe sequence numbers and windows). I just never felt like it.

I also like their other examples, with the improved SCTP connection mechanism (with the cookie), and the simpler hangup one.

Don't get me wrong, TCP is cool, and for most (line-oriented) internet protocols just great, but SCTP seems better designed and cleaned up, i.e. a little bit more mature.

Re:Cool thing (1)

autOmato (446950) | more than 8 years ago | (#14853602)

UDP isn't safe, so you'd have to implement half of TCP anyway (re-transmit, maybe sequence numbers and windows)

Unless, of course, you don't care in which order you receive your datagrams or whether some got lost on the way.

Anyway, I wasn't trying to say that I think SCTP is crap or unneccessary or anything. It's just that I can't come up with a concrete situation, where SCTP would be the perfect protocol to use. Since you said SCTP is a protocol you have always wanted, I assumed you had a specific application in mind where UDP+Reliability or TCP+Frames would be the way to go but a hassle to implement.

Re:Cool thing (1)

Ulrich Hobelmann (861309) | more than 8 years ago | (#14853612)

No, nothing specific, but I like messaging architectures, for instance, and de/serializing everything so it can go over a normal stream socket is a bit annoying. At least if you do it in one process with threads you can skip the whole thing (just pass a pointer to a structure).

Linux to Linux (-1, Flamebait)

matt me (850665) | more than 8 years ago | (#14853378)

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?

Re:Linux to Linux (0)

Anonymous Coward | more than 8 years ago | (#14853427)

"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."

Re:Linux to Linux (0)

Anonymous Coward | more than 8 years ago | (#14853452)

STFU, noob.

Re:Linux to Linux (1)

alexmipego (903944) | more than 8 years ago | (#14853490)

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 [alexandre-gomes.com]

Re:Linux to Linux (1)

diegocgteleline.es (653730) | more than 8 years ago | (#14853557)

There're many system supporting SCTP according to this page [sctp.org] . 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.

Re:Linux to Linux (4, Informative)

lasindi (770329) | more than 8 years ago | (#14853641)

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 [softlab.ntua.gr] 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.

Services file? (1)

TallMatthew (919136) | more than 8 years ago | (#14853398)

Does this mean all the IANA ports are now open for SCTP?

Please add the following to your /etc/services:

tallmatthew 25/sctp

SCTP vs TCP benchmarks (5, Informative)

Anonymous Coward | more than 8 years ago | (#14853442)

Re:SCTP vs TCP benchmarks (2, Interesting)

six (1673) | more than 8 years ago | (#14853524)

Interestingly, SCTP falls behind TCP in the majority of cases (more latency, less bandwidth).

The exception being the HTTP tests, where I guess they used only one tcp connection to the server with no keepalive (something that no web browser would do in the real world, most opening 2 or 4 tcp connections with keepalive).

I can't see a real advantage of multi-stream SCTP over multiple TCP connections ... Someone in the know care to elaborate ?

Re:SCTP vs TCP benchmarks (1)

AnonymousPrick (956548) | more than 8 years ago | (#14853585)

Interestingly, SCTP falls behind TCP in the majority of cases (more latency, less bandwidth).

You've brought up a question I have. I see SCTP can handle more than one stream, but what's the effect on the underlying hardware layer? In other words, you have multiple streams going at once; wouldn't that just divide up the bandwidth you have?

Re:SCTP vs TCP benchmarks (5, Funny)

amorsen (7485) | more than 8 years ago | (#14853611)

In other words, you have multiple streams going at once; wouldn't that just divide up the bandwidth you have?

What would you like it to do, magically go faster than the bandwidth you have?

Re:SCTP vs TCP benchmarks (1)

AnonymousPrick (956548) | more than 8 years ago | (#14853620)

What would you like it to do, magically go faster than the bandwidth you have?

Other than possibly making multistreaming network software easier to develop, what's the point of SCTP?

Low message delivery latency (2, Informative)

butlerm (3112) | more than 8 years ago | (#14853986)

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.

Re:SCTP vs TCP benchmarks (2, Insightful)

ROOK*CA (703602) | more than 8 years ago | (#14853748)

What would you like it to do, magically go faster than the bandwidth you have?

I think the point is to use what you have more effeciently, if real "bandwidth" is measured as the transfer rate of actual payload from point A to point B, then using it more effeciently (less overhead) does actually increase "bandwidth", not magic but it does allow me to go "faster" than I can without utilizing those more effecient technique(s).

Re:SCTP vs TCP benchmarks (1)

the eric conspiracy (20178) | more than 8 years ago | (#14854000)

What I want is QTCP, quantum transport control protocol where the packets arrive at the destination without having to go through the intervening network.

Re:SCTP vs TCP benchmarks (2, Interesting)

ROOK*CA (703602) | more than 8 years ago | (#14853621)

I can't see a real advantage of multi-stream SCTP over multiple TCP connections ... Someone in the know care to elaborate ?

Good question

Perhaps this provides a bit of insight: From the article:
"Multi-streaming is an important feature of SCTP, especially when you consider some of the control and data issues in protocol design. In TCP, control and data typically share the same connection, which can be problematic because control packets can be delayed behind data packets. If control and data were split into independent streams, control data could be dealt with in a more timely manner, resulting in better utilization of available resources."

I suspect (although it's not explicitly stated) that SCTP multi-streaming offers less resource consumption of the end points than multiple TCP connections do.

Benchmarks measure LKSCTP not SCTP (2, Interesting)

butlerm (3112) | more than 8 years ago | (#14853809)

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 [fh-muenster.de]

FreeBSD, Darwin (4, Informative)

Midnight Thunder (17205) | more than 8 years ago | (#14853538)

Seems like there is an implementation [www.sctp.de] for FreeBSD and Darwin (underlying OS used by MacOS X) too, according to this page.

Fyi Darwin is dead (0)

Anonymous Coward | more than 8 years ago | (#14853687)

http://ezine.daemonnews.org/200602/apple.html [daemonnews.org]

Thanks Apple! Oh and before you cry Troll about the article do some basic research on the author.

Re:Fyi Darwin is dead (1)

Midnight Thunder (17205) | more than 8 years ago | (#14853754)

Actually Apple did release the necessary stuff, they were just late. Check the darwin-dev mailing list.

Re:FreeBSD, Darwin (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14853712)

The End of FreeBSD

[ed. note: in the following text, the former FreeBSD developer Mike Smith gives reasons for abandoning FreeBSD]

When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

Discussion

I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

Shouts

To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.

To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.

To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.

To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.

Future

I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.

However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.

You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.

= Mike

--

read the RFC (4, Insightful)

darthscsi (144954) | more than 8 years ago | (#14853539)

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.

Kernel space name resolution not required (5, Informative)

butlerm (3112) | more than 8 years ago | (#14853894)

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.

Re:read the RFC (2, Interesting)

hehman (448117) | more than 8 years ago | (#14853966)

It reads as though they just decided the whole layered protocol thing was overrated and shoved every new feature into this one layer.

I couldn't disagree more. SCTP moves a lot of things that should be done in the transport layer there, instead of making applications re-implement heartbeats and failover and message boundaries and so forth for the 1000th time.

How this compares WRT DCCP? (3, Interesting)

diegocgteleline.es (653730) | more than 8 years ago | (#14853544)

The Linux network stack is having tons of new things lately, SCTP [wikipedia.org] is one, but how it compares with DCCP [wikipedia.org] , 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?

Re:How this compares WRT DCCP? (4, Informative)

ChristopherX (956137) | more than 8 years ago | (#14853663)

DCCP and SCTP are not very related. DCCP is an improvement on UDP - DCCP is an unreliable protocol that improves upon UDP by being aware of, and throttling back upon, network congestion.

Other possible future TCPs (5, Informative)

rev_karol (735616) | more than 8 years ago | (#14853565)

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 [hamilton.ie]
Interesting plots too [hamilton.ie]
The end result is that TCP is not particularly suited to high-speed networks.

SCTP and IPv6 (0)

Anonymous Coward | more than 8 years ago | (#14853577)

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.

YAGNI !!! (1)

nietsch (112711) | more than 8 years ago | (#14853707)

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.

Good news and bad news (1)

UnknowingFool (672806) | more than 8 years ago | (#14853679)

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! :)

4-way handshake (2, Interesting)

tidewaterblues (784797) | more than 8 years ago | (#14853703)

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.

Re:4-way handshake (2, Insightful)

Detritus (11846) | more than 8 years ago | (#14853834)

The denial-of-service attack will not work if the attacker uses forged source addresses, as is common with TCP.

Does this matter with TCP/IP offload and iWarp? (3, Informative)

soldack (48581) | more than 8 years ago | (#14853727)

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

Interesting. Not a bad idea (4, Informative)

Animats (122034) | more than 8 years ago | (#14853762)

It's always been a bit strange that TCP, which is a streaming protocol and ignores message boundaries, is the standard for request/response message type traffic. You have to add a framing protocol on top of TCP to do messaging, which is what everybody does.

The first attempt in the IP world to add a protocol of this type was Reliable Data Protocol, in 1984. (See RFC 908 [faqs.org] ). 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

In other news... (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14853878)

Linux is STILL for fags.

Sounds similar to TIPC (2, Informative)

AaronW (33736) | more than 8 years ago | (#14853941)

This sounds somewhat similar to TIPC [sourceforge.net] 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

SCTP in need of a working shim (2, Interesting)

Raul654 (453029) | more than 8 years ago | (#14853995)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>