![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
What is a "Message" in this given context? -- 194.113.59.80 ( talk) 09:47, 5 August 2008 (UTC)
"All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step."
The page currently states "TCP ensures byte order by conceptually assigning a sequence number to each byte sent and ordering these bytes based on that sequence number when they arrive.", but I find this claim very awkward and misleading: TCP does not reorder bytes, it reorders the payloads of separate packets. As I understand it, each packet contains the sequence number of the last byte it contains, which simply used as the basis for reordering. Furthermore, the link to the article 'byte order' is entirely irrelevant as the target article talks about Endianness which has nothing to do with stream reassembly.
I made an edit hoping to be more clear, but it was reverted by User:Cburnett with the message "TCP packet data cannot be randomly rearranged and be accepted as "good", therefore the data in a packet must be in the same byte order as sent". Am I missing the point? Obviously TCP cannot randomly reorder bytes or payloads. The whole issue is about guaranteeing that the individual packet payloads are reassembled in the order they were initially written to the stream. -- intgr 20:01, 13 April 2006 (UTC)
i notice this protocol is mentioned quite a lot in various wikipedia networking articles yet it doesn't even seem to be supported on windows! This would seem to indicate to me that its unlikely to be used much outside niche applications. Plugwash 22:36, 5 November 2005 (UTC)
Good to know but i can't see how a protocol not supported by windows can gain any traction for end user apps. maybe for special networks where compatibility with clients using the standard desktop os isn't required but not for general use.
BTW i'm not arguing that this article should be far from it its just if this is a hardly used niche protocol it should be identified as such. Plugwash 01:02, 10 February 2006 (UTC)
Information about the status of this protocol in real-world deployments should be added to the article. -- Beland 19:47, 22 September 2007 (UTC)
Fast forward a few years. STCP still looks good on paper. Legacy telephone and SS7 along with it is being overrun by VoIP. Some refs indicated that SIP can be carried via STCP but that is not mentioned on Wikipedia or in RFC 3261; does anyone actually do this? www.sctp.org was last updated in 2004. What's going on? -- Kvng ( talk) 17:48, 15 July 2011 (UTC)
I have a few problems with the way the Packet Structure tables have been set up.
— Kbolino 22:08, 7 March 2006 (UTC)
As a long term telephony (SS7) person, seeing sigtran becoming more and more requested by major operators, I have a slight concern about the speed of detection of link failures, which doesn't seem to be discussed here. SCTP speeds up link failure discovery when compared with TCP, thanks to the heartbeats, but the algorithm used to determine link failure is identical to that used in TCP. As a result of that, with RFC stated defaults, it's possible for a link to be down for (if memory serves, not got the RFC in front of me) 2 or 3 seconds (RTTMIN==1000 ms, retransmit attempts==2?); compare that with tradition TDM based SS7 signalling, with FISUs going back and forth constantly, and link failure detected in milliseconds. 3 seconds outage on a typical SCP (prepaid, VPN, toll-free), or SMSC could, potentially, result in thousands of lost, or at least delayed, messages.
Not sure of the point of this rambling, but it's something I'm concerned about, and am curious to see other people's opinions.
Is the comparison table in Transport_layer#Transport_protocol_comparison_table really correct? Now SCTP seemes to be equivalent to TCP. Please add rows to the table that pinpoints the major differences. Mange01 07:54, 27 June 2007 (UTC)
Maybe merge this section with Transport_layer#Comparison_of_TCP.2FIP_transport_protocols? It would feel more ‘neutral’ to me if the comparison of the different protocols were on a different page than on one of the compared protocols’. kess ( talk) 19:07, 20 May 2009 (UTC)
Done --
Kvng (
talk)
15:12, 29 November 2010 (UTC)
Stream Control Transmission Protocol is not a proper noun as far as I believe and from the guidelines in WP:MOS. 87.254.89.197 ( talk) 01:51, 1 March 2009 (UTC)
DCCP appears exactly once in the article as a column heading in the transport control protocol. DCCP appears to accomplish some of the same things as SCTP. Some discussion of DCCP comparing and contrasting the two in the article would be helpful -- Kvng ( talk) 03:46, 16 May 2009 (UTC)
There are two identical criterias: Reliable transport Unreliable transport —Preceding unsigned comment added by 212.154.22.58 ( talk) 08:36, 18 May 2009 (UTC)
The term "transaction" is common in the realm of databases and possibly memory systems where a set of changes must be made "atomically"--that is, all or nothing--to maintain consistency. I do not believe this term is appropriate in networking. In networking a more essential distinction is that between "streams" and "messages". In this article I prefer the term "message-oriented" over "transaction-oriented". IOLJeff ( talk) 21:15, 3 July 2009 (UTC)
The Packet Structure section states "SCTP packets have a simpler basic structure than TCP or UDP packets." OK, TCP arguably, but UDP? UDP has 5 fields including the data payload. Even a single chunk SCTP packet has 8. I'm removing the reference to UDP, though if anybody thinks this is a goof feel free to reinstate it. Jonathan. —Preceding unsigned comment added by 86.216.134.185 ( talk) 14:34, 21 February 2010 (UTC)
You say as the first paragraph: "In computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role as the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both, ensuring reliable, in-sequence transport of messages with congestion control. It seems that you're stating that UDP allows in-sequence transport because you say "serving in a similar role as ...TCP and UDP. It provides some of the same service features of both:....reliable, in-sequence transport".
UDP is not reliable nor guarantees in-sequence transport.—Preceding unsigned comment added by Dwilches ( talk • contribs) 21:29, 27 April 2010
The external links section was full of reference type items. This would be a good resource for someone who wants to improve the article or add citations. I don't think these comply with WP:EL and I don't think these are of direct use to most readers. -- Kvng ( talk) 15:26, 29 November 2010 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Stream Control Transmission Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 23:50, 25 April 2017 (UTC)
The text states that ordering is optional, and that the receiver may choose to process ordered packets in an unordered fashion. The RFC states ( https://tools.ietf.org/html/rfc4960#section-6.6) that ordered packets must be delivered to the upper layer in the correct order, which apparently contradicts this statement. Could somebody with better knowledge of SCTP verify this, and add a reference or remove the statement. RogierA7 ( talk) 13:33, 9 December 2017 (UTC)
The referenced (and unreadable due to paywall) IEEE source doesn't seem to be related to the statement that ssh implements SCTP; I have found no references that it would nor found any instance of the string "sctp" in openssh source. I would like to see a direct reference to ssh changelog or source please. I doubt its correctness, to put it nicely. -- grin ✎ 18:44, 13 August 2020 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
What is a "Message" in this given context? -- 194.113.59.80 ( talk) 09:47, 5 August 2008 (UTC)
"All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step."
The page currently states "TCP ensures byte order by conceptually assigning a sequence number to each byte sent and ordering these bytes based on that sequence number when they arrive.", but I find this claim very awkward and misleading: TCP does not reorder bytes, it reorders the payloads of separate packets. As I understand it, each packet contains the sequence number of the last byte it contains, which simply used as the basis for reordering. Furthermore, the link to the article 'byte order' is entirely irrelevant as the target article talks about Endianness which has nothing to do with stream reassembly.
I made an edit hoping to be more clear, but it was reverted by User:Cburnett with the message "TCP packet data cannot be randomly rearranged and be accepted as "good", therefore the data in a packet must be in the same byte order as sent". Am I missing the point? Obviously TCP cannot randomly reorder bytes or payloads. The whole issue is about guaranteeing that the individual packet payloads are reassembled in the order they were initially written to the stream. -- intgr 20:01, 13 April 2006 (UTC)
i notice this protocol is mentioned quite a lot in various wikipedia networking articles yet it doesn't even seem to be supported on windows! This would seem to indicate to me that its unlikely to be used much outside niche applications. Plugwash 22:36, 5 November 2005 (UTC)
Good to know but i can't see how a protocol not supported by windows can gain any traction for end user apps. maybe for special networks where compatibility with clients using the standard desktop os isn't required but not for general use.
BTW i'm not arguing that this article should be far from it its just if this is a hardly used niche protocol it should be identified as such. Plugwash 01:02, 10 February 2006 (UTC)
Information about the status of this protocol in real-world deployments should be added to the article. -- Beland 19:47, 22 September 2007 (UTC)
Fast forward a few years. STCP still looks good on paper. Legacy telephone and SS7 along with it is being overrun by VoIP. Some refs indicated that SIP can be carried via STCP but that is not mentioned on Wikipedia or in RFC 3261; does anyone actually do this? www.sctp.org was last updated in 2004. What's going on? -- Kvng ( talk) 17:48, 15 July 2011 (UTC)
I have a few problems with the way the Packet Structure tables have been set up.
— Kbolino 22:08, 7 March 2006 (UTC)
As a long term telephony (SS7) person, seeing sigtran becoming more and more requested by major operators, I have a slight concern about the speed of detection of link failures, which doesn't seem to be discussed here. SCTP speeds up link failure discovery when compared with TCP, thanks to the heartbeats, but the algorithm used to determine link failure is identical to that used in TCP. As a result of that, with RFC stated defaults, it's possible for a link to be down for (if memory serves, not got the RFC in front of me) 2 or 3 seconds (RTTMIN==1000 ms, retransmit attempts==2?); compare that with tradition TDM based SS7 signalling, with FISUs going back and forth constantly, and link failure detected in milliseconds. 3 seconds outage on a typical SCP (prepaid, VPN, toll-free), or SMSC could, potentially, result in thousands of lost, or at least delayed, messages.
Not sure of the point of this rambling, but it's something I'm concerned about, and am curious to see other people's opinions.
Is the comparison table in Transport_layer#Transport_protocol_comparison_table really correct? Now SCTP seemes to be equivalent to TCP. Please add rows to the table that pinpoints the major differences. Mange01 07:54, 27 June 2007 (UTC)
Maybe merge this section with Transport_layer#Comparison_of_TCP.2FIP_transport_protocols? It would feel more ‘neutral’ to me if the comparison of the different protocols were on a different page than on one of the compared protocols’. kess ( talk) 19:07, 20 May 2009 (UTC)
Done --
Kvng (
talk)
15:12, 29 November 2010 (UTC)
Stream Control Transmission Protocol is not a proper noun as far as I believe and from the guidelines in WP:MOS. 87.254.89.197 ( talk) 01:51, 1 March 2009 (UTC)
DCCP appears exactly once in the article as a column heading in the transport control protocol. DCCP appears to accomplish some of the same things as SCTP. Some discussion of DCCP comparing and contrasting the two in the article would be helpful -- Kvng ( talk) 03:46, 16 May 2009 (UTC)
There are two identical criterias: Reliable transport Unreliable transport —Preceding unsigned comment added by 212.154.22.58 ( talk) 08:36, 18 May 2009 (UTC)
The term "transaction" is common in the realm of databases and possibly memory systems where a set of changes must be made "atomically"--that is, all or nothing--to maintain consistency. I do not believe this term is appropriate in networking. In networking a more essential distinction is that between "streams" and "messages". In this article I prefer the term "message-oriented" over "transaction-oriented". IOLJeff ( talk) 21:15, 3 July 2009 (UTC)
The Packet Structure section states "SCTP packets have a simpler basic structure than TCP or UDP packets." OK, TCP arguably, but UDP? UDP has 5 fields including the data payload. Even a single chunk SCTP packet has 8. I'm removing the reference to UDP, though if anybody thinks this is a goof feel free to reinstate it. Jonathan. —Preceding unsigned comment added by 86.216.134.185 ( talk) 14:34, 21 February 2010 (UTC)
You say as the first paragraph: "In computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role as the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both, ensuring reliable, in-sequence transport of messages with congestion control. It seems that you're stating that UDP allows in-sequence transport because you say "serving in a similar role as ...TCP and UDP. It provides some of the same service features of both:....reliable, in-sequence transport".
UDP is not reliable nor guarantees in-sequence transport.—Preceding unsigned comment added by Dwilches ( talk • contribs) 21:29, 27 April 2010
The external links section was full of reference type items. This would be a good resource for someone who wants to improve the article or add citations. I don't think these comply with WP:EL and I don't think these are of direct use to most readers. -- Kvng ( talk) 15:26, 29 November 2010 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Stream Control Transmission Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 23:50, 25 April 2017 (UTC)
The text states that ordering is optional, and that the receiver may choose to process ordered packets in an unordered fashion. The RFC states ( https://tools.ietf.org/html/rfc4960#section-6.6) that ordered packets must be delivered to the upper layer in the correct order, which apparently contradicts this statement. Could somebody with better knowledge of SCTP verify this, and add a reference or remove the statement. RogierA7 ( talk) 13:33, 9 December 2017 (UTC)
The referenced (and unreadable due to paywall) IEEE source doesn't seem to be related to the statement that ssh implements SCTP; I have found no references that it would nor found any instance of the string "sctp" in openssh source. I would like to see a direct reference to ssh changelog or source please. I doubt its correctness, to put it nicely. -- grin ✎ 18:44, 13 August 2020 (UTC)