text:
Talk:Transmission Control Protocol

Maximum Segment Size
When you read this section "Furthermore, TCP senders can use path MTU discovery to infer the minimum MTU along the network path between the sender and receiver, and use this to dynamically adjust the MSS to avoid IP fragmentation within the network.", you can say it implies that:

1. MSS can be derived from the Path MTU 2. MSS can be adjusted after it is sent to the other end.

MSS can be calculated based on the MTU of the locally attached network, and not the minimum MTU along the path (PMTU). MSS can not be adjusted after it is sent (only) in the [SYN] packets during the three-way handshake. So better to change the lines or the wordings. — Preceding unsigned comment added by WikiJackool (talk • contribs) 05:01, 16 January 2016 (UTC)

TCP ports
Regarding
 * Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private.

It seems like it might make sense to link to Portmap and possibly even the "little used" TCP Port Service Multiplexer pages as examples of dynamic port usage (with liaison on a well-known port). JimD (talk) 00:56, 20 June 2015 (UTC)

Denial of service
I think the phrase "purposely assembled SYN packets" should be replaced with "degenerate SYN packets" in this section as this would more accurately convey that the such packets are malicious and not conformant to the relevant standard semantics. — Preceding unsigned comment added by JimD (talk • contribs) 00:48, 20 June 2015 (UTC)

TCP is not a virtual circuit protocol
TCP is not a virtual circuit because the connection state resides only on the two send systems. Any intermediate nodes are not aware of any of the TCP parameters. Fisherisland14 19:27, 25 September 2006 (UTC)

 * TCP is a virtual circuit protocol because the connection state resides. Intermediate nodes need not be aware of any parameters for a protocol to establish a virtual circuit. Here are two external definitions:
 * : A connection between communicating computers that provides the computers with what appears to be a direct link but can actually involve routing data over a defined, but longer path. - no mentions of necessity of intermediate nodes being aware of anything.
 * : A defined connection between two end-points in a packetized network. While the two ends of the virtual circuit are defined, the path used by the network to connect the two end-points is not necessarily predetermined. - explicitly said that intermediate nodes not important. Nikola 15:07, 13 October 2006 (UTC)

TCP state diagram be useful?

 * After pondering this for a while, I'd say "no", because I think it would be too detailed for Wikipedia. We're not supposed to be an expert-level reference work - that's what "Further reading" and "External links" are for. I mean, do we really want to get into "Fin-Wait-1" and such things here? I think not... Noel 13:01, 4 Oct 2004 (UTC)

 * I think the answer is YES! A diagram would be the most concise and useful expression which shows how TCP really works.  By your arguement, the whole listing of the states in TCP in words should be deleted.  I feel that Wikipedia readers that come to the very detailed page, should get a proper diagram of the TCP state machine.  Note also that the graphic in RFC 793 is text-based and very hard to read.  Wikipedians deserve a really nicely drawn one.  Mike 4 Jan 2005

 * I agree that the state diagram is useful. However it only includes the set up and tear down phases of TCP - it doesn't expand on the "data transfer" state, which should have data ACK and ACK states showing the data flow. 22 Nov 2006

This is an issue. The so called state diagram popularized in network books are highly simplified view- though none of the books makes it aware to their readers and propagate the myth that this diagram is actually the TCP state diagram. Indeed, all it illustrates are the connection establishment and connection closing part of TCP and leaves out all states. The states pertaining to its real run time operation has been lumped in just one box - ESTABLISHED. But it has been taken care of. In 2005 a detailed  state diagram has been created from the original RFC and drawn using formal  EFSM language. A pointer to it exists in the external reference section. Thanks. JIK 2007.

 * NB - That EFSM document is pretty rubbish, it contains dozens of errors. The connection establishment flow doesn't work because the flow diagrams don't check that the outstanding SYN has been acknowledged before transitioning to ESTABLISHED; the closing handshake doesn't work because the FIN packets omit ACK, which would cause them to be dropped by the receiver... it's a real mess, I don't know how the authors arrived at it, but it clearly wasn't double-checked against a working/functional TCP implementation. We should remove the links to it I think, it's misleading. 2A02:390:A001:192:D6BE:D9FF:FE9C:1892 (talk) 16:51, 29 April 2019 (UTC)

IMHO the simplified state machine is useful, but it lacks a transition: from the LAST ACK state to the CLOSING state, the endpoint has to receive an ACK segment in order to change its state. Andrea Spadaccini, 2008. —Preceding unsigned comment added by 151.97.6.24 (talk) 09:52, 27 August 2008 (UTC)

Checksum
The TCP checksum -- isn't it more properly referred to as the one's complement of the one's complement sum? In any case, I'm removing the link to one's complement in the article, because that gives a *very* misleading impression of how to calculate the checksum.--Ryan Stone 19:01, 8 Nov 2004 (UTC)

 * RFC 793 calls it the one's complement of the one's complement sum, so that's what I'm putting in the article.--Ryan Stone 19:08, 8 Nov 2004 (UTC)

Yes, it's the complement of the sum, so that when you receive a packet, you don't have to zero out the checksum field (after first storing the checksum), and then compare the checksums afterwards - you just sum up the packet, with the received checksum in situ, and the resulting sum should be 0 (actually all 1's, which is also zero in one-comp notation - there's no way to add up any sequences of non-zero numbers and get 0 as the result in one's-comp addition, due to the wrap-around add of the carry). I'll add this to the article, along with why we used a ones-comp sum to begin with. Noel (talk) 14:22, 14 Nov 2004 (UTC)

Is it really appropriate to have the ellipsis after the Network Layer enumeration of IPv4, IPv6, and ARP? Are there really other network layer protocols?

TCP windows or Windows' TCP
In the paragraph titled TCP window size: "The Windows TCP/IP stack is designed to self-tune itself" - do you mean Microsoft Windows ? (Since "window" generally means something else in this paragraph). If yes, make it explicit. If no, why the word order and capitalization?

This confused me too, so I googled the phrase. It looks like that paragraph was ripped off of [Microsoft] (I really doubt the other way 'round....). Anyway, in the context of the microsoft article, it clearly refers to Microsoft Windows 200x.

Ah, both the Window scaling and the Window size sections are ripped off of that MS article. Probably more.
 * Jeff 02:11, July 12, 2005 (UTC)

Software limitations -- totally unreliable claims
From the article:

 * Networking speed gradually increased over the years. What started as a protocol built for unreliable low speed networks (few Kbytes per second) is now required to run at 1 Gigabit per second. The TCP software implementations on host systems require extensive computing power. Gigabit TCP communication, alone, eats up 100% of a 2.4 GHz Pentium 4 processor.

The latter point is totally uncited, and omits several facts that are essential to judge the statement. For instance, TCP implementations vary widely, as to OS responses to high load, particularly I/O load. What operating system was this metered on? What kind of load was used? I would expect, for instance, that a 2.4GHz Pentium 4 being used as an Ethernet bridge in Linux, using zero-copy forwarding, would have very different performance characteristics from one being used as an FTP server in Windows.

These claims need to be cited with details, or else they should be deleted. --FOo 02:34, 27 Jun 2005 (UTC)

 * Agreed. My 2.0 GHz 2400+ XP Athlon w/ 512 MB ram running 2.6 gentoo linux sees hardly any CPU time for my gigabit card.  Cburnett 04:15, Jun 27, 2005 (UTC)

 * Almost ALL GOC ( Gigabit over copper ) cards today, have CPUs on the cards, that with the use of jumbo frames reduces CPU utilization. "The reduction in CPU utilization is achieved primarily by allowing the host to transmit large frames (frames larger than the links Maximum Transmission Unit or MTU) to the NIC which are subsequently carved up into smaller, MTU-sized frames by the NIC, before transmission on the wire. Thus instead of processing many small MTU-sized frames during transmit, the host sends fewer larger VMTU (Virtual MTU) sized frames thereby increasing the efficiency of the data transfer in the host. The VMTU is typically much larger than the links MTU; for example, on a typical Ethernet card, the link MTU is 1500 bytes while a VMTU could be as large as 64Kbytes. Greater than 50% reduction in CPU utilization has been observed on some FTP workloads."  —Preceding unsigned comment added by 67.174.157.126 (talk) 22:18, 5 May 2008 (UTC)

 * Removed since I think it's sufficiently wrong to merit proof for inclusion. Cburnett June 28, 2005 07:58 (UTC)

Would like to add that the statement "Linux kernels (from 2.6.8) have enabled TCP Window Scaling ..." is out of place. If we are going to include various OS and OS version specific comments, the list would be huge, and absolutely unmanageble.Libertate 16:37, 2 February 2007 (UTC)

NPOV?
Forgive me if I'm incorrect, I'm a newb at wikipedia. Doesn't this bit go against the whole "neutral point of view" philosophy?

"A better solution..."

It almost sounds like whoever put that bit in was just trying to advertise "NTA"

 * That paragraph seemed to be simply an advertisement. That's not just an "NPOV" violation, it's spam. (To the person who added it -- please learn how not to be a spammer.) Deleted. --FOo 14:32, 1 August 2005 (UTC)

Paragraph "Data Transfer" is duplicated
The paragraph "Data Transfer" appears twice in the article, once in its own paragraph and once under Connection Termination further down,
 * I have checked this item and I propose mark it as .--Jimmy Olano (talk) 18:49, 4 August 2019 (UTC)

State diagram
The german article is a featured article so when I checked it out I noticed that it had a state diagram: de:Bild:Tcp verbindung.png. If anyone feels like doing a little editting to change the german to english...that'd be spiffy. Cburnett 06:16, 22 February 2006 (UTC)
 * Done. Raul654 07:03, 22 February 2006 (UTC)

"Active Open" / "Passive Open" in connection terminating state box, should be "Active Close" / "Passive Close" respectively?

Termination: a three- or four-way handshakes
There was a point of contention regarding the number for describing the handshake process in the connection termination. Someone recently reverted an edit to say it is four, not three.

The teardown seems to be very similar to the setup: Each side sends a FIN and responds with an ACK, making the process:

1. Side A sends a FIN packet 2. Side B responds with an ACK/FIN 3. Side A responds with an ACK

This seems the most likely way most teardowns operate. A half-open connection where B acknowledges without sending the FIN could cause it to be four-way, of course, but this seems rather rare. Perhaps it could be:

"three- or four-way depending on the first response."

--Kevin L'Huillier 02:41, 10 March 2006 (UTC)

 * It's a 3 way handshake. Every scintilla of literature on the subject refers to it as a 3-way handshake. Raul654 02:48, 10 March 2006 (UTC)

 * Okay. I will revert the revert, but also add that it could take four steps if it is intentionally left half-open. --Kevin L'Huillier 04:47, 10 March 2006 (UTC)

Yes, it's commonly a 3-way handshake by combining the FIN & ACK together. However, the process is really a 4-way (FIN1, ACK1, FIN2, ACK2) and the 3-way is merely an "optimization".

To me, a "way" in handshake is an agreement of the state of a channel. Prior to closing either end the channel is open. The first FIN indicates the sender has closed its end. The corresponding ACK acknowledges the state (2 ways). At this point the state is agreed to be half-open. The non-initiator can optionally bundle its FIN with the ACK if it has nothing to send (why would you send 2 packets when you can send one???). Finally the initiator ACKs the non-initiators close. So, in all, it is a 4-way handshake — there are four steps to completely close a connection.

On a related tangent, an ACK is a 2-way handshake. The sender's data is acknowledged thus "stating" that the data has been received. The ACK is usually bundled with other data because there's no reason to transmit a separate packet for a flag and a few bytes. The 3-way handshake is the exact same scenario: just bundling an ACK on some sender's data (a FIN).

Raul, every scintilla? You might try the TCP/IP Protocol Suite by Forouzan (ISBN 0-07-246060-1) on page 328 (2nd ed). It describes it as a four-way handshake.

Regardless, I believe my version is down the correct road. Explain it all sufficiently so the reader understands it and can take it as they please. Saying it's a 4-way because that's what it is, and adding that there are common optimizations is the best approach. Cburnett 01:12, 11 March 2006 (UTC)

 * Additionally, Raul, look at the very RFC that defines TCP: RFC 793. Page 23 shows the state diagram for TCP.  There are two paths:
 * 3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> FINWAIT-2 -> TIME WAIT
 * 3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> CLOSING -> TIME WAIT
 * The first path is the non-initiator closing after the initiator closes. The second path is the case when both ends close simultaneously (both receive the FIN before receiving their ACK).  So it's clearly a 4-way: the reception of an ACK is distinct from receiving the FIN. Cburnett 01:28, 11 March 2006 (UTC)

 * Even-more-additionally: The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference by Charles Kozierok (ISBN 159327047X) describes it as a pair of two-way handshakes. Cburnett 04:37, 12 March 2006 (UTC)

Everyone has made good points.

A related question is: Why is the establishment considered three-way? It is conducted in a very similar manner ie. it could be SYN, ACK, SYN, ACK instead of the usual SYN, SYN/ACK, ACK. Should it be considered a pair of two-way handshakes, and therefore four-way as well?

--Kevin L'Huillier 03:01, 28 March 2006 (UTC)

 * I guess I'd have to wager it's not a 4-way because whether or not the SYN/ACK is split up the connection cannot continue. If A SYNs and B ACKs then A cannot send data because it hasn't ACK'ed B's SYN. Regardless, one or two packets for the SYN/ACK doesn't change the connection state: A cannot send until it's ACK'ed B's SYN.

 * This contrasts highly with termination where B can still send data to A until B sends a FIN to A. There is clearly a state change (A can no longer send data) that doesn't exist in connection establishment.

 * I have also never seen the connection be referred to a 4-way. Not wanting to fall into the argumentative trap Raul fell in, I'll point out tha if connection were considered a 4-way then I'd beleve that would come from the same sources that say termination is a 4-way handshake but they don't.  They all say 3-way.

 * So it's not the number of packets or flags sent, but the number of state changes that matter. Cburnett 04:16, 28 March 2006 (UTC)

 * Ah, that makes perfect sense. Thank you. --Kevin L'Huillier 18:14, 29 March 2006 (UTC)

I believe the answer to these questions are as follows: Sharhalakis (talk) 00:06, 24 March 2016 (UTC)
 * A connection is 3-way. There is no implementation of a 4-way handshake for connection establishment and that would most probably be wrong. Nodes A and B sending pure SYN packets would indicate the initiation of two connections (with the same port pair). Only one of them will succeed. A responding SYN *must* have the ACK bit set and the proper ACK# in the segment to indicate and prove that it is a response to the initial SYN. A responding SYN without the ACK cannot prove that is a response to the initial SYN (as the ACK# would be ignored without the ACK bit).
 * A termination is a 4-way process that under certain conditions can be compressed to 3 packets. Termination is a two-way process as already mentioned above: One end indicates that they have nothing else to transmit and the other acknowledges that, indicating that it received all data, including the FIN. The receiving end of the first FIN *may* indicate a termination on their side too by adding the FIN to the ACK, but that situational. I believe that this can be caused only by delayed ACKs and retransmissions. E.g. when the ACK to a FIN is delayed enough so that a FIN also becomes available (but I guess that's implementation specific). To fully understand this you need to understand how the FINs originate: FINs are sent when an application calls shutdown for their transmitting side (or close on the socket). Now picture two applications working over the Internet: It is not practically possible for them to simultaneously close the connection, meaning that one will close first. In all such cases, where delayed ACKs and lost packets don't come into play, there will be 4 packets transmitted.

Poor definition methodology
Just making a simple observation: Several examples in this article casually use the accronym TCP in its own definition, which is generally considered poor practice. E.g. ...Any SYN packet holds Sequence Number. The Sequence Number is a 32-bit field TCP segment header...

In this case it could be considered confusing to the laymen to use the subject of the article in its own definition.

Comment: But does it really matter? Laymen wouldn't understand the details of the protocol anyway...and are probably not interested in try to understand them. —Preceding unsigned comment added by 74.93.1.129 (talk • contribs)

iTCP
I'm in two minds about whether this should be here as this is more about research than TCP. What are others thoughts? In the meantime I'm fixing the grammar and links up a little... --Imcdnzl 00:21, 16 May 2006 (UTC)
 * I've asked Oldiowl to tone this down a bit as it sounds like an advertisment for iTCP at the moment. --Imcdnzl 03:45, 16 May 2006 (UTC)

Thanks for your comments. I have toned it down. See if it reads better?

Just a note.. iTCP also has FreeBSD impelementation. It is just new. Note many others linked/explained/pointed variants of TCP are also predominantly research system. Fast TCP, TCP Hybla, H-TCP, are in this class. Many even have no record of implementation. However, it is possibly Ok to list such research grade systems for discussions of current transport protocols.

I tried to follow TCP Hybla pointer but it does not seem to point to a page with obvious connection to a TCP protocol description. Does anyone know about this link? thanks, Oldiowl

OK. I'm editing this after reading about iTCP some more. It is actually quite interesting and relevant to my research but the edits on this page are inaccurate and do not need the prominence that they have been given.--Imcdnzl 21:10, 18 May 2006 (UTC)

Datagram
What is a datagram, and does TCP count as a Datagram? Mathiastck 21:25, 13 July 2006 (UTC)

What I have been told at university is that "Datagram" is the name of the PDU for UDP, while "Segment" is the name of the PDU for TCP. El pak

 * It would improve this article greatly to respond to questions with adding simple explanations to the article, and not left as an excercise for the reader. —Preceding unsigned comment added by 67.174.157.126 (talk) 22:22, 5 May 2008 (UTC)

Few responses to above
As someone who originally did much of this article, I'd like to challenge the whole notion of 3-way and 2-way termination handshake. I don't believe that is really any such thing, I think what this is, is some stacks "cheating", but I'll dig into it to verify. And the 2-way handshake, that certainly sounds made up. Going by the state diagram and calling it 2-way or 3-way based on that is a bit misleading I think. In any case, I don't believe anyone ever refers to the connection termination as a handshake and pretty sure never a 3-way or 2-way handshake, but I'm prepared to be proven wrong. ...and we refer IP datagrams, UDP messages and TCP segments, but most people tend to say "packets" and that is generally fine unless one is being particularly pedantic. It looks the article needs some other minor updates since I last looked and I'll try to do my share soon.

History
There's no mention of who developed TCP, or how it came to be. —Preceding unsigned comment added by 62.79.44.136 (talk • contribs)
 * Thank you for your suggestion! When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the  link at the top. You don't even need to log in (although there are many reasons why you might want to).  The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills.  New contributors are always welcome. --FOo 07:51, 15 August 2006 (UTC)
 * There is a good history at Internet protocol suite which contains TCP within it, so if you wanted more, also consider putting it there instead. — RevRagnarok  Talk Contrib 10:45, 15 August 2006 (UTC)

"TCP Reno"
To the best of my knowledge, "TCP Reno" is a name invented by Larry Peterson, and not used by many other researchers. At the time Van Jacobson was developing the original congestion mitigation algorithms, it was expected that they would be released in 4.4BSD. Development of 4.4 took much longer than anticipated, and an interim release, 4.3BSD-Reno (successor to 4.3BSD-Tahoe), was made to get the code out into the hands of ISVs. It was published in the "Networking 1" release about the same time. 18.26.0.5 22:25, 11 September 2006 (UTC)

Application/transport dependency misnomer
From the article: "Common applications that use TCP include HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (e-mail) and FTP (file transfer)."

The phrasing in the article tacitly implies that as part of their specification application layer protcols must use TCP. This is not entirely accurate. From RFC 2616:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. —Super j dynamite 04:56, 19 September 2006 (UTC)

 * That may be true in a pedantic sense but the reality is that http is used either directly with TCP or with SSL over TCP. Are there even any standard url schemes that can specify a http connection over something other than TCP or SSL over TCP? Plugwash 11:01, 22 October 2006 (UTC)

over time diagram?
What do you think of adding that kind of diagram to the article? I personally find them simpler to understand than the state diagram. I'll try to do a draft tonight (EST). -- lucasbfr talk 14:15, 11 October 2006 (UTC)

what do you think? -- lucasbfr talk 00:38, 17 October 2006 (UTC)
 * The visual quality doesn't match what is already present in the article. Additionally, it is confusing where the actual data communication occurs - you seem to be showing a very limited one-shot request, like HTTP or something. I think I'd prefer to break it into two images with "setting up" and "taking down" separated. — RevRagnarok  Talk Contrib 10:55, 17 October 2006 (UTC)
 * Thanks for your input. As I said, that's a draft more than anything else. I'll see if I come with something else. -- lucasbfr talk 13:27, 17 October 2006 (UTC)

 * I was actually looking for a diagram like this in the main article! May be a trace screenshot from WireShark would suffice. 21 November 2006

 * This type of diagram is often used to simplify the explanation of state machines; I frequently use them in teaching. When I don't have time to tell students how to read a state machine, I give them call flows like this instead. I vote use these with a sentence or two of explanation in place of state machine diagramswhich require about 30 minutes of lecture to get a student up to speed in reading one.  I have mixed feelings, however, because the state machine on this page is a work of art.  Ngriffeth 14:04, 3 July 2007 (UTC)

SYN Merge
Not enough info on SYN for a good article, and ACK already redirects here. --Ortzinator 15:18, 27 October 2006 (UTC)

 * Sounds like a good idea to me: One specific packet type of a protocol is probably a little over-specific. DStaal 18:27, 27 October 2006 (UTC)

 * Merge, such as it was, done. Guy Harris 00:25, 22 November 2006 (UTC)

Remarks
Someone should change sentences like "TCP is optimized for ...". TCP is developed for wired networks, but not optimized for such scenarios. Mathematicians can optimize something, engineers improve something! And have a look outside the USA. Good ideas how to improve TCP are not restricted to USA researchers. Therefore, I have added a link to my two-year old (!) dissertation. —The preceding unsigned comment was added by 217.247.67.233 (talk) 03:03, 9 December 2006 (UTC).

 * To the best of my knowledge, the problems with TCP over wireless haven't been solved, they've merely been ameliorated somewhat. The problem is that TCP assumes that dropped packets mean congestion, because that's almost always the case in current highly reliable wireline networks. Obviously, wireless networks drop packets for many reasons.  Ngriffeth 14:07, 3 July 2007 (UTC)

Termination,
can anyone comment about the following quote: "Finally, it is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions."

I think this is impossible... and anyway (see the discussion about termination below) it's the number of state changes that matters and not the number of packets.

I think this sentence should be removed.

Achituv 14:50, 19 April 2007 (UTC)

 * It's possible. What they are talking about is if both sides decide, simultainiously, to close the connection.  (So they both request it.)  Depending on how you look at it, it even results in one less state change: Both sides change state on their own to 'ready to end', and the other side would then reply that it is also ready.  (Instead of one side triggering the state change in the other.)

 * It is somewhat confusing as a sentance however. (Though I'm obviously not sure how to clean it up.) DStaal 15:12, 20 April 2007 (UTC)

It this Correct, I beleave that it is the direction that is closed, not the end. If I close for send I can still receive. (it would also be good to see mapping between BSD API and protocal.)

 * A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into or receive any data from the connection, but the other side can (but generally if it tries, this should result in no acknowledgment and therefore a timeout, or else result in a positive RST, and either way thereby the destruction of the half-open socket). —Preceding unsigned comment added by 204.193.45.69 (talk) 11:23, 12 March 2009 (UTC)

TCP segment structure
Anybody got the RFC that explicitly backs up the segment structure displayed? I know its implied in the RFC's but I cannot find an RFC that backs this version up, and it is distictly different from http://tools.ietf.org/html/rfc793#page-15

--Whisper555 07:31, 3 July 2007 (UTC)

I hate to say this because these are nice diagrams, illustrate the headers nicely and in the appropriate way, and they're almost entirely accurate (more accurate would be more confusing anyway). However...

The inclusion of two diagrams, the first diagram combining the IPv4 header with the TCP header and the second diagram combining the IPv6 header with the TCP header is extremely confusing. The only reason I was able to decode this is because I'm used to network layering, know the IP headers by heart, and I just finished writing a program to dissect network headers based on a new definition language for them (I used the language definitions to check the fields in the TCP segment header - they're essentially correct - and I also am actively using the language definitions to dissect TCP segments, so these headers do correspond to what's in use in the Internet - but for the record, we must also consult the IETF documents).

Anyway, this seems like waaaaaay too much information for anyone - if I want the official version of TCP headers, I'll go to the IETF site anyway, so having them here means wikipedia has to keep tracking what's going on at IETF to keep them up to date, and anyone who really needs this level of info is going to go to IETF to get the official version

I'm tempted to just delete this, but first, could someone explain what the purpose of including it was so we can consider whether there's a better way to communicate the ideas? Ngriffeth 14:28, 3 July 2007 (UTC)
 * Come now. The TCP headers don't change that much, that often. :) The point I was making is that the current diagram & subsequent explanations do not match RFC 793. I personally know why they don't, but that doesn't mean everybody else will, and it is confusing if you do look at half the resources on the Internet & in books which match the RFC 793 and the other half do not, and in Wikipedias case, without explanation or citation. I am not going to commit suicide if it is not changed, but this is my simple suggestion to hopefully create a better, more authoritative article. --Whisper555 03:29, 4 July 2007 (UTC)
 * Sorry, I was just threatening to be aggressive (isn't that recommended by the Wikipedia guidelines? :-)) I compared the wikipedia diagram with the RFC793 diagram in section 3, page 14.  I see two differences that are completely inconsequential as far as correctness and a third that is indeed interesting but only to people who really care: (1) the spacing on the wikipedia diagram gives the visual impression that the first 16 bits of each word are longer than the last 16 bits, which is obviously not true and I assume not intended, and redrawing the diagram to fix that would definitely be good and (2) the padding field that's included in the RFC is missing here (the padding field documents the fact that if the options don't end on a word boundary, then padding is inserted - seems likely to be confusing to  lay reader since padding is likely not to be there in any given packet).  The other difference is that two flag bits have been added to the flags field, using a couple of the reserved bits.  Let me congratulate you, picking up these two bits takes incredibly careful reading!!  Because it incorporates these bits, the wikipedia diagram is more up-to-date than 793 (as is to be expected, since 793 is really old and has been updated by several subsequent rfc's).  Take a look at RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP.  Omigod that's mean - the title really doesn't give you a clue about the change to TCP.   You should be able to find this kind of change by following the "updated by" links in the index to RFC's.   But then again, if you do this and look at the title.... you probably just keep looking.  As to textbooks, some are more up-to-date than others; also, I don't think 3168 is a standard yet, it's just an RFC.  And versions of TCP that incorporate ECN should be backwards compatible anyway.  And not all versions of TCP will incorporate it even after it's a standard.  Sigh, life is so complicated.  Ngriffeth 19:32, 11 July 2007 (UTC)
 * The above discussion actually supports my argument. It's hard to track the changes to RFC's, and it's an unnecessary burden in maintaining a wikipedia article, which (correct me if I'm wrong) is intended for a layperson, not an expert.  Only an expert needs the level of detail we just got into. Also, back to my biggest concern, even if the diagrams are appropriate it's a bad idea to confound the IP and TCP headers this way.  Convinced yet?  (Excuse my verbosity, I'm just excited to talk to someone who cares about this stuff :-). )   And I'm definitely open to leaving it if there's a chance it could be more useful than a link to the IETF.  Ngriffeth 19:32, 11 July 2007 (UTC)
 * I tried to clarify as best I could by adding headers to the TCP header tables, and breaking them into sections. --Unixguy 15:01, 13 July 2007 (UTC)
 * Yes, that helps. I'm gong to put in a pointer to RFC 3168 for the flag fields. Ngriffeth 17:15, 13 July 2007 (UTC)
 * 1. Great work. 2. I'm so evil. :) There are so many threads on forums around the world, you all have probably been involved yourselves at some point, where people either complain about their high speed broadband not downloading at the speeds they expect, OR their little Gigabit home networks fail to run at true Gigabit speeds and they don't know why. The explanation for how Windowing for high speed high latency (in relative terms) as set out in http://tools.ietf.org/html/rfc1323 leaves a bit to be desired, especially in reagards to what gets changed in the TCP Segment when rfc1323 is implemented at both ends. Surely it must be possible to provide a decent explanation in more or less the same amount of words / space as is currently alloted to http://en.wikipedia.org/wiki/SYN_Packet#TCP_window_size . This article is marked as confusing or unclear for some readers before I showed up, so lets see what we can do, hey? That is to say, I have some technical knowledge about TCP-IP and I will try to bring to your attention sections that make me feel I know less than I did, before I read that section, that is to say, if somebody who supposedly has idea of what something is, is confused, hows your regular wikipedia reader going to fair?. :) --Whisper555 18:23, 31 July 2007 (UTC)

I tried to address the problem with the field sizes appearing wrong, by making each bit the same size. Someone decided that stacking the bit numbers vertically was confusing, so I used <tt> (and &nbsp; for 1-9) to get consistent sizing back. I'm not sure I like that as well as I did the stacked numbers. Sample:                 1 1 1 1 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Is this really that hard to understand? The Monster (talk) 23:37, 18 September 2009 (UTC)

what is tcp actually for?
what does this do?

Read the TCP article ;) Burningmace 20:22, 23 July 2007 (UTC)

It's used to clean bathtubs, so I hear.

Nah. TCP is an internet protocol. It's well known for its use in HTTP communication (between a web browser and a web server), but it can be used for other things too, such as online games. Comparing it with UDP might help put it in context. — xDanielx T/C 00:11, 16 August 2007 (UTC)

 * TCP is Great for cleaning tubs, but in this context, it is a method or proticall, much like the proticall Bocce, it is great for negotiating the transfer of binay and ascii data in short bursts or long transfers, for HTTP transmissions or FTP transmissions. ( Jumbo packets are best for faster connectsions ). —Preceding unsigned comment added by 67.174.157.126 (talk) 02:45, 6 May 2008 (UTC)

Sequence number - in bytes?
Why does the sequence number label bytes of a packet, rather than each packet as a whole? When would that complication ever be useful? I've looked all over for the answer to this and I haven't found it. The only thing I can think of is if an end system received *part* of a packet, a part that had the full header and only some of the data. Then the receiving party could send back a sequence number that was supposed to be in the middle of a packet. However, this seems like something that probably isn't done in reality. Anyone with some ideas? Fresheneesz 20:06, 8 November 2007 (UTC)

 * RFC 3168 suggests it helps with spoof prevention. It also helps simplify the receiver since when packets arrive out of order, it doesn't have to queue and map them into the destination message:  it can simply use a (validated) sequence number for the location within the message buffer.  That simplifies SACK as well. —EncMstr 20:46, 8 November 2007 (UTC)

 * The reason that TCP sequence numbers are in bytes is that you don't have a proper mapping between packets and bytes. Consider a scenario where you send a packet containing 10 bytes. That packet is lost. After a while retransmission occurs. But, by now you have an additional 10 bytes to send. This means that the retransmission will hold 20 bytes, and not the 10 of the first transmission. Which sequence number should you use for this retransmission? The same as the original packet? If so, then the ACK that comes back might be for either only 10 bytes, or possibly for 20.

 * While I like the argument here; as I understand it, this is not how TCP works according to the original RFC. Segments are put on a retransmission queue, and when the timer goes off, the segment is retransmitted exactly as it was sent out in the first place. Is the behaviour you describe here specified somewhere else as an extension to the protocol? Or is it an optimisation used only in (certain) implementations? I'm interested to know so if anybody has a word on this, please contact me. — Preceding unsigned comment added by Lars nl 1 (talk • contribs) 12:55, 30 May 2013 (UTC)

 * If, on the other hand you use a new sequence number, how would the receiver then know that we skipped a sequence number in the packets?
 * In short, if you were to use sequence numbers on packets, then you would severly reduce the flexibility and the performance of TCP. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

 * Labeling the bytes is also nicely consistent with TCP's providing a byte stream rather than a message stream. And while almost nothing ever uses it, labeling the bytes probably also helped simplify Out Of Band data processing. Perfgeek (talk) 00:07, 10 August 2009 (UTC)

Established connection sockets
I always wonder what happens to the listening socket after establishing a connection with it? Lets say there is a software server (Svr) listening at port x, then a client C connects (handshakes and all). Now we know that a connection is established between Svr & C on port x, yet, the server is still listening for new connections on port x. So how can the same port be used by an established connection and for listening to new connections at the same time?

In other words: How does a server like a web server, for example, handles multiple connections simultaneously on the same port number?

Thanks

Ai.unit (talk) 21:37, 18 November 2007 (UTC)

 * I think that's generally the point of sockets being a combination of port and IP, the server obviously can't get a new connection from the same IP on the same port as it would have no way to identify which was which (except maybe the window but that's far from reliable). The way I'm doing at the minute for my embedded stack is to have the port and socket info slightly separate.  If a connection comes in on a port from an IP not associated with the port it sets up a new connection as it's obviously very simple to distinguish, while existing connections on the port may not be listening.  Basically the port is in perpetual listen but a socket on that port may not be.  I don't know if that's exactly how it's meant to be done but seems the most sensible way to me. - Y_Less 15:58, 23 November 2007 (GMT)

 * OK you can get multiple connections from the same IP on the same port as it uses remote port too which is essentially random, i.e. a http connection will connect to port 80 but connect from any port which the server can use to reply - Y Less (talk) 11:34, 27 November 2007 (UTC)

 * Good question Ai! I came to this page looking for exactly the answer to this question (which was just troubling me generally). I read the whole article to look for the answer, before reading the talk page. I think the talk page should be the place to look for improvements to the article, but not for relevant questions on the subject. I vote that this information be moved to the main page. --Dmg46664 (talk) 21:56, 1 May 2008 (UTC)

 * Hint: Look at the header of a TCP Packet. 67.174.157.126 (talk) 02:47, 6 May 2008 (UTC)

 * A TCP connection is actually identified by both of its endpoints, not just one. So a connection is the combined information of the local IP address, the local TCP port, the remote IP address and the remote TCP port. So, obviously there aren't any problems with several connections to the same local IP address and TCP port, as long as the remote ends differ. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

This page.
Reading this page just made my brain leak.--163.248.159.162 (talk) 18:32, 3 September 2008 (UTC)
 * Yeah, it' unfortunately bad written. --178.197.225.145 (talk) 14:05, 14 January 2014 (UTC)

Error on Nagle
This article states that Nagle is an algorithm for avoiding the silly window syndrome. That is just plain wrong, and should also be obvious if you follow the link to the Nagle algorithm, which describes it. Nagle is for avoiding silly small packets, not silly small windows. There is a very important difference between these, as they occur for very different reasons. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

You're right. I've removed this erroneous comment. — Preceding unsigned comment added by 2001:468:C80:4391:B565:DD4A:186C:BBFC (talk) 16:08, 23 April 2013 (UTC)

The TCP state diagram is inaccurate
The boxes for the closing procedures are incorrectly explaining them as active/passive opens. —Preceding unsigned comment added by 212.146.94.66 (talk) 12:01, 15 September 2008 (UTC)

I corrected the problem. --Sergiodc2 (talk) 10:35, 16 October 2008 (UTC)

TCP v4 ?
The article refers to RFC 793 as "TCP v4" in two places. Why? I've heard TCPv4 used, rarely, to mean "TCP on top of IPv4", as opposed to "on top of IPv6", but I'm not sure that's what the article is aiming for. It's not particularly interesting either. The RFC itself doesn't mention "v4" or "version 4". And it sure doesn't claim there were ever any TCP v1, v2, or v3.

JöG (talk) 20:53, 12 November 2008 (UTC)

TCP v2 and TCP v3 are defined in the IEN (internet experiment note) series which has quite a bit detail about the early evolution of TCP. 85.212.91.129 (talk) 13:06, 29 November 2015 (UTC)

acknowledgemnts
The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. This sentence is misleading. Modern TCP implementations will send multiple packets before waiting for an acknowledgment. --Jeoth (talk) 04:18, 19 December 2009 (UTC)

UDP checksum is required in IPv6
Section 4.3 says that UDP checksums are optional. This is true for IPv4, but not for IPv6. 130.221.224.7 (talk) 02:51, 11 March 2011 (UTC)

 * I removed the UDP comparison. It didn't seem necessary. Correcting it would have brought us even further off point. --Kvng (talk) 02:45, 13 March 2011 (UTC)

IP component to complemet IP
I read right in the beginning: "TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP." Are you ok? Somebody is loosing fuck*** ground here. --Javalenok (talk) 12:59, 28 April 2011 (UTC)

Unclear section 4.10 Connection Termination
Whoever added the last part in Connection Termination, can you please add some more details. I have a graduate degree in CS, but I still did not clearly understand this part: "Some application protocols may violate the OSI model layers, using the TCP open/close handshaking for the application protocol open/close handshaking - these may find the RST problem on active close." The example code is showing how NOT to do it, can you also post how to DO it? Also more clarification needed here: "For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data arrives to the other application." Thanks. — Preceding unsigned comment added by 64.134.66.244 (talk) 00:14, 12 July 2011 (UTC)

TCP is used in internet radio, but not always for multi room audio
Just to document edit. Internet radio uses TCP. Most internet radio stations are played with a delay, thus TCP packet recovery can be used. For Multi room audio (such as in Sonos, Streamium, Apple Airtunes) UDP makes for a simpler implementation. However some systems will still use a TCP implementation since it reduces the implementation overhead. For this you need to synch clocks — Preceding unsigned comment added by Ursushoribilis (talk • contribs) 09:10, 21 August 2011 (UTC)

"TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another"
This is wrong and need to be corrected. http://www.stratus.com/blog/openvos/?p=749 --Frederico1234 (talk) 13:58, 1 September 2011 (UTC)

uhhh. what?
"If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168)."

This sentence makes no sense... — Preceding unsigned comment added by 24.246.4.28 (talk) 14:04, 24 September 2011 (UTC)
 * Many sentences in this article make no sense whatsoever. I don't want to offend anybody, but some things should be rewritten for that at least English speaking tech (!) people can understand it. --178.197.225.145 (talk) 14:08, 14 January 2014 (UTC)

Category for discussion: Category:TCP/IP -> TCP / Transmission Control Protocol
Everyone kindly is invited to take part in the discussion to rename Category:TCP/IP, please see: Categories for discussion/Log/2012_August_9. -- intgr [talk] 16:07, 13 August 2012 (UTC)

Octets vs. bytes
This article uses both terms. Should we choose one or the other. Please discuss at Wikipedia_talk:WikiProject_Computing/Computer_networking_task_force. ~KvnG 14:20, 16 August 2013 (UTC)

Choice of diagrams
There are two versions of the TCP state diagram in this article, File:Tcp state diagram fixed.svg (currently used) and File:Tcp state diagram fixed new.svg (currently ). For those who cannot see the difference, the second has an ACK/- on the transition between Closing and Time/Wait on the "Active Close" path. I'm not really much of an expert, but I think that is the correct version - with my opinion influenced by Transmission Control Protocol, which uses File:Tcp_verbindung.png, which has the ACK/- in question. Can we get a consensus on which of the images to use? --Stephan Schulz (talk) 11:27, 4 January 2014 (UTC)
 * The new diagram is correct. The non-bold "ACK/-" means that an ACK message is received, and that no message is sent; it is the receipt of an ACK that causes the transition from CLOSING to TIME WAIT. The source is [//tools.ietf.org/html/rfc793#page-23 RFC 793] (hard-to-read ASCII art), and a clearer diagram (which a quick look makes me think is correct) is here. Johnuniq (talk) 00:09, 5 January 2014 (UTC)

Misleading coloring of checksum
The use of the same color of the IP pseudo header and the TCP checksum is very misleading. The checksum must have a different color than the IP pseudo headers. --178.197.225.145 (talk) 13:44, 14 January 2014 (UTC)
 * Color changed, however the text describing the calculation of the TCP checksum is still not clear. I needed to do an intrernet search to find out how it really works, I found this useful site: http://www.daemon.org/tcp.html

 * There it says: "checksum (16 bits) A sixteen bit checksum on the tcp header (including, of course, any tcp options that are present), data, and a 96 bit pseudo header made up of..." which sounds a lot more clear to me than : "The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octetispaddedon the right with zeros to form a 16-bit word for checksum purposes. [...]" I mean, what the heck is "text"?!?! --178.197.225.145 (talk) 13:57, 14 January 2014 (UTC)

Orphaned article about to be deleted
Dear editors, there is an orphaned article called TO-TCP (terminal originated TCP) that has been marked for deletion. Do any of you see any reason to rescue it? Thanks in advance. TheAMmollusc (talk) 11:54, 15 May 2014 (UTC)

Broken link in "Other"
The link to visualland.net seems to be broken, which is a shame as animations are always useful. We should consider removing the link. Kthelgason 22:44, 18 September 2014 (UTC)

Can someone please check the sequence number used in client's ACK for the 3-way handshake? I believe this is incorrect and should be using the initial sequence number
— Preceding unsigned comment added by Kthelgason (talk • contribs)

sequence number
Today sequence number redirects here to Transmission Control Protocol.

Is there a more general article that discusses sequence numbers, that would be more appropriate for sequence number to redirect to? While the most common sequence numbers may be TCP sequence numbers, I see that many other Wikipedia articles mention sequence numbers of various sizes -- alternating bit protocol, B protocol, High-Level Data Link Control, etc. -- none of which are TCP sequence numbers.

My understanding is that many of those protocols are examples of a sliding window protocol.

A few Wikipedia articles mention sequence numbers that are used in things that don't seem to be a sliding window protocol, such as YAFFS and Common Log File System.

Is TCP a sliding window protocol? (One commenter at talk: sliding window protocol seems to think it is not).

Is there a more general article that would be better for sequence number to redirect to, perhaps an article that discusses a more general category of things that use sequence numbers? --DavidCary (talk) 18:39, 4 February 2015 (UTC)

 * Perhaps it should be a disambiguation page instead? Or at least start it that way, to see what different kinds of sequence numbers show up and if a general article on the topic even makes sense. -- intgr [talk] 19:12, 4 February 2015 (UTC)
 * Agreed. @DavidCary: Hope you don't mind but I edited your comment to use no redirect. Yes, TCP uses a sliding window and it is quite likely that a technical person wanting information about "sequence number" on the Internet is thinking of its use in TCP. However, as you say, there are lots of other topics. A dab page to start would be best. Johnuniq (talk) 09:02, 5 February 2015 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on Transmission Control Protocol. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive http://web.archive.org/web/20110312114242/http://www.ilmondodelletelecomunicazioni.it:80/english/telematics/protocols.html to http://www.ilmondodelletelecomunicazioni.it/english/telematics/protocols.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 14:52, 27 February 2016 (UTC)

Confusing table
That table showing tcp content is confusing. It is using octets, bits and offsets but you can figure out which is which. Colums and rows are impossible to follow and read corectly. — Preceding unsigned comment added by 86.123.128.88 (talk) 13:00, 13 April 2016 (UTC)

 * If you're talking about Transmission Control Protocol, I think it's fairly clear. Each row is 32 bits (4 octets) and the columns refer to bits or fields within each 32-bit unit. This is also the same format how the RFC specifies the TCP header. If you have suggestions for improving it, go ahead. -- intgr [talk] 11:49, 14 April 2016 (UTC)

Forcing data delivery section is wrong
There's no 200ms delay on send. That's the "delayed ACK" timer, which is at the receive end. TCP does not have an accumulation timer, like an X.25 PAD does. This only affects special situations where the sender sends multiple small packets which don't generate responses. It doesn't affect bulk file transfers. John Nagle (talk) 23:29, 18 August 2016 (UTC)
 * It's possible to meet very informed people at Wikipedia! I once had a reasonable grasp of Nagle's algorithm but that was years ago, and only as a user of TCP/IP. I see that the wording is wrong—I guess the point they attempted to make is that if a process at A sends 1 byte to TCP for delivery to B, then B will wait for 200 ms before replying with an ACK (assuming no data from B to A is sent). Meanwhile, assuming the process at A sends more, the TCP at A will wait for the ACK before sending the additional data. So, after the first byte, there is a delay before another byte is sent, and the delay may be up to 200 ms plus round-trip time. Any chance of some suggested wording to fix the section? Johnuniq (talk) 11:17, 19 August 2016 (UTC)
 * Right. But that delay only applies to packets smaller than the maximum packet size. If there's enough data to fill a packet, it goes out anyway. This is done to prevent sending lots of tiny packets instead of one big one. John Nagle (talk) 06:41, 20 August 2016 (UTC)
 * Understood—it's hard making a simple statement about TCP that covers all cases! Johnuniq (talk) 07:01, 20 August 2016 (UTC)

Resource usage
" [...]the client must allocate a random port before sending the first SYN to the server. This port remains allocated during the whole conversation, and effectively limits the number of outgoing connections from each of the client's IP addresses. If an application fails to properly close unrequired connections, a client can run out of resources and become unable to establish new TCP connections, even from other applications."

This part is not clear -- how is the fact that the client allocates a port upon connection "effectively limits the number of outgoing connections from each of the client's IP address"? Is it because there is a "limited number of ports"? What limit is refereed to here? YuvalAloni (talk) 17:44, 20 December 2016 (UTC)
 * It's a long time since I thought much about TCP but I think the text is based on the premise that a server is probably running a small number of well-designed applications where things that are opened are eventually closed, so the server is good. However, anyone can write code for a typical client, and bad code might not close connections. The port is specified with a 16-bit number, so 65536 ports are available for TCP at a server and at a client. That is the limit, and really broken software could use all the ports which would prevent further connections. The same consideration applies at the server which generally listens on port 0. However, the server will establish a TCP connection on a randomly chosen port so there is no difference between the server and client. Johnuniq (talk) 03:29, 21 December 2016 (UTC)

Protocol Operation
Could someone please tell why only TIME_WAIT is marked "either server or client"? Is there any problem if we state "both server and client" for this one too? -- Kuratowski (talk | contribs) 11:10, 3 October 2017 (UTC)

Adequate summary
Problem:

I propose translate from the french Wikipedia Transmission Control Protocol (according to the licensing rules):

"Transmission Control Protocol (TCP)is a reliable, connected-mode transport protocol documented in IETF,.

In the Internet model, also known as the TCP / IP model, TCP is located above IP. In the OSI model, it corresponds to the transport layer, intermediate of the network layer and the session layer. Applications transmit streams of data over a network connection. TCP breaks the octets stream into segments whose size depends on the MTU of the underlying network (data link layer).

TCP was developed in 1973 and then adopted for ARPANET in 1983, replacing NCP."

Plase consider it, thanks! --Jimmy Olano (talk) 18:41, 4 August 2019 (UTC)

 * I don't think we would improve things by replacing the current lead with what you propose. Maybe we could merge the two together. The real problem here is that, while what we have is a competent high-level description of TCP, we're missing a summary a lot of the content in the body of the article. ~Kvng (talk) 13:31, 7 August 2019 (UTC)
 * You are right: I want substitute the summary, I am using only the WP:TECHNICAL style. Let's wait and think better, meanwhile others wikipedians may contribute too; have a nice day!--Jimmy Olano (talk) 14:03, 7 August 2019 (UTC)

Do the changes since this post constitute a good enough summary to remove the tag? Rauisuchian (talk) 00:47, 27 December 2019 (UTC)
 * I think it's good and removed the tag, thanks. Johnuniq (talk) 02:51, 27 December 2019 (UTC)

"TCPSTACK" listed at Redirects for discussion
An editor has asked for a discussion to address the redirect TCPSTACK. Please participate in the redirect discussion if you wish to do so. Steel1943 (talk) 07:23, 26 January 2020 (UTC)

Possible reverse copyvio
This page by Vskills seem to derive from the Connection establishment to the Connection termination sections, without crediting the editors of those sections or linking to this article. Major contributors to those sections, as well as the uploader of File:TCP CLOSE.svg might want to talk to the website's admin about it. pandakekok9 (talk) 11:42, 23 July 2021 (UTC)

What about time arrows on sequence diagram?
Is it possible to add arrow heads and labels (t for time) at bottom of the figure, which is a sequence diagram? This would help clarity. — Preceding unsigned comment added by Brutzman (talk • contribs) 15:49, 6 August 2021 (UTC)

 * Time increases in the down direction in these diagrams but not necessarily in proportion to distance. It is describing a sequence of events one following another as per the indicated arrows. If we turned it upside down or sideways, it would still make sense without labeling time. ~Kvng (talk) 18:00, 13 August 2021 (UTC)

Citation would be nice on the opening paragraph.
The introduction has citations only for wikipedia. Having some sources outside of this website would be lovely. - MountainKemono (talk) 15:38, 6 December 2022 (UTC)

 * We don't require citations in the lead per WP:WHENNOTCITE. That said, there is not good support for the assertion that TCP is one of the main protocols of the Internet protocol suite in the body of the article. This is not a controversial statement IMO and is well supported (but not clearly well cited) in Internet protocol suite. ~Kvng (talk) 16:09, 11 December 2022 (UTC)
 * My apologies for the way I worded that. I believe that is what I was trying to point out in the introduction. I will have to do some source finding to see where that takes me and update appropriately. - MountainKemono (talk) 10:45, 12 December 2022 (UTC)

title: Talk:Transmission Control Protocol


text: Category:History of Korea

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Category:History of Korea


text:
Province of Brescia

The province of Brescia (provincia di Brescia; Brescian: pruìnsa de Brèsa) is a province in the Lombardy region of Italy. It has a population of some 1,265,964 (as of January 2019) and its capital is the city of Brescia.With an area of 4,785 km2, it is the biggest province of Lombardy. It is also the second province of the region for the number of inhabitants and fifth in Italy (first, excluding metropolitan cities).

It borders the province of Sondrio to the north and north west, the province of Bergamo to the west, the province of Cremona to the south west and south, the province of Mantua to the south. On its northeastern border, Lake Garda – Italy's largest – is divided between Brescia and the neighboring provinces of Verona (Veneto region) and Trentino (Trentino-Alto Adige/Südtirol region).

The province stretches between Lake Iseo in the west, Lake Garda in the east, the Southern Rhaetian Alps in the north and the Lombardian plains in the south. The main rivers of the province are the Oglio, the Mella and the Chiese.

Besides Brescia, other important towns in the province are Travagliato, Darfo Boario Terme, Desenzano del Garda, Palazzolo sull'Oglio, Montichiari, Ghedi, Chiari, Rovato, Gussago, Rezzato, Concesio, Orzinuovi, Salò, Gardone Val Trompia and Lumezzane.

Geography

The province of Brescia is the largest in the region, boasts three main lakes, Lake Garda, Lake Iseo and Lake Idro, plus several other smaller lakes, three valleys, Val Camonica, Val Trompia and Valle Sabbia, as well as a wide flat area south of the city, known as the Bassa Bresciana, and several hilly areas surrounding the city landscape and extending eastwards towards Veneto and west to Franciacorta.

Due to the altitude and morphological variety and the presence of large lakes, the province includes all kinds of biomes in Europe: from something similar to the maquis shrubland up to the perennial snow of Adamello (with the largest glacier in the Italian Alps).

Valleys
The three main valleys on the territory of Brescia are the Val Camonica, crossed by the river Oglio and inserted in the northwestern part of the province from Adamello to Lake Iseo; Val Trompia, the river Mella basin, between the municipalities of Concesio and Collio; and the Valle Sabbia which includes the municipalities from Serle to Bagolino along the course of the river Chiese.

All the three valleys have the point of union the Croce Domini Pass, which takes the name from the "cross" formed by the union of the three basins.

Lakes
Within the province there are eight lakes. The main lake basin, in both dimensional, climatic and cultural terms, is Lake Garda, shared with the Veneto and Trentino regions, which with its 370 km2 of surface is the biggest lake in Italy. Because of its size, the lake has a considerable influence on the climate and the surrounding environment, generating a micro-geographic area in a more mitigated climate both in summer and winter.

Lake Iseo is the second lake of the area, and is situated at about 180 m above sea level, in an area called Sebino, between Val Camonica (north) and Franciacorta (south), which divides the provinces of Bergamo and Brescia.

Lake Idro, the third lake within the provincial territory, is located in Valle Sabbia, on the border between Brescia and the province of Trento, and differs from the other two main lakes for its modest size. The waters of the lake are mainly exploited for the irrigation of crops in contiguous territories, as well as for the production of energy through a small power plant located in the municipality of Vobarno.

Other small lakes in the province are: Lago della Vacca (at an elevation of 2,358 m, in one of the coldest points of the province), Lago d'Arno, Lago Aviolo, Lago Baitone, Lago Moro and Lago di Valvestino.

Rivers
There are about 45 watercourses crossing the territory of the province, but almost all of them are torrents. The only watercourses that can be defined as real rivers are just three: Oglio, Chiese and Mella; divided between the three main valleys.

Extreme points

 * Highest point: Mount Adamello, Saviore dell'Adamello (3,539 m)
 * Highest settlement: Tonale Pass, Ponte di Legno (1,883 m)
 * Northernmost municipality: Ponte di Legno
 * Southernmost municipality: Fiesse
 * Easternmost municipality: Limone sul Garda
 * Westernmost municipality: Pontoglio

UNESCO World Heritage Sites

 * Rock Drawings in Valcamonica;
 * Brescia, one of the places of Longobard power;
 * Prehistoric settlements of Lavagnone (Desenzano del Garda), Lugana Vecchia (Sirmione), Lucone (Polpenazze del Garda), San Sivino and Gabbiano (Manerba del Garda).

Castles and fortress

 * Castle of Brescia;
 * Castle of Sirmione;
 * Castle of Lonato;
 * Bonoris Castle;
 * Castle of Desenzano;
 * Castle of Breno;
 * Fortress of Anfo;
 * Castle of Padenghe;
 * Castle of Padernello;
 * Castle of Pozzolengo;
 * Castle of Carzago;
 * Castle of Bornato;
 * Castle of Drugolo;
 * Castle of Pontevico.

Other sights

 * Lake Garda, Lake Iseo and Lake Idro;
 * Stelvio National Park;
 * Adamello Regional Park;
 * Alto Garda Bresciano Regional Park;
 * Torbiere del Sebino Natural Reserve;
 * Earth pyramids of Zone Natural Reserve;
 * I Borghi più belli d'Italia: Bienno, Gardone Riviera, Montisola and Tremosine;
 * Grandi Giardini Italiani: Vittoriale degli Italiani, Isola del Garda, Giardino Botanico Andrè Heller, Le Vigne di Bellavista - Franciacorta;
 * Natural monuments of Buco del Frate, Altopiano di Cariadeghe, Baluton and Masso del Permico;
 * Ski resorts of Ponte di Legno, Temù and Montecampione in Valcamonica;
 * Franciacorta wine region;
 * Grottoes of Catullus.

Government
The Province of Brescia is an administrative body of intermediate level between a municipality (comune) and Lombardy region.

The three main functions devolved to the province of Brescia are:
 * local planning and zoning;
 * provision of local police and fire services;
 * transportation regulation (car registration, maintenance of local roads, etc.).

As an administrative institution, the province of Brescia has its own elected bodies. From 1945 to 1995 the President of the province of Brescia was chosen by the members of the Provincial Council, elected every five years by citizens. From 1995 to 2014, under provisions of the 1993 local administration reform, the President of the Province was chosen by popular election, originally every four, then every five years.

On 3 April 2014, the Italian Chamber of Deputies gave its final approval to the Law n.56/2014 which involves the transformation of the Italian provinces into "institutional bodies of second level". According to the 2014 reform, each province is headed by a President (or Commissioner) assisted by a legislative body, the Provincial Council, and an executive body, the Provincial Executive. President (Commissioner) and members of Council are elected together by mayors and city councilors of each municipality of the province respectively every four and two years. The Executive is chaired by the President (Commissioner) who appoint others members, called assessori. Since 2015, the President (Commissioner) and other members of the Council do not receive a salary.

In each province, there is also a Prefect (prefetto), a representative of the central government who heads an agency called prefettura-ufficio territoriale del governo. The Questor (questore) is the head of State's Police (Polizia di Stato) in the province and his office is called questura. There is also a province's police force depending from local government, called provincial police (polizia provinciale).

This is a list of the Presidents of the Province since 1945:

Comuni
Here is a list of the most populated comuni (municipalities) of the province.

Subsequently, a list of the municipalities divided into their geographical zone (municipalities with more than 15,000 inhabitants are in bold):
 * Capital city area: Brescia, Borgosatollo, Botticino, Bovezzo, Collebeato, Concesio, Gussago, Nave, Rezzato, Roncadelle.
 * Franciacorta: Rovato, Palazzolo sull'Oglio, Adro, Cellatica, Capriolo, Coccaglio, Erbusco, Cazzago San Martino, Passirano, Paderno Franciacorta, Castegnato, Rodengo Saiano, Ome, Monticelli Brusati, Polaveno.
 * Lake Iseo: Iseo, Marone, Monte Isola, Paratico, Pisogne, Provaglio d'Iseo, Sale Marasino, Sulzano, Zone.
 * Val Camonica: Darfo Boario Terme, Angolo Terme, Artogne, Berzo Demo, Berzo Inferiore, Bienno, Borno, Braone, Breno, Capo di Ponte, Cedegolo, Cerveno, Ceto, Cevo, Cimbergo, Cividate Camuno, Corteno Golgi, Edolo, Esine, Gianico, Incudine, Losine, Lozio, Malegno, Malonno, Monno, Niardo, Ono San Pietro, Ossimo, Paisco Loveno, Paspardo, Pian Camuno, Piancogno, Pisogne, Ponte di Legno, Saviore dell'Adamello, Sellero, Sonico, Temù, Vezza d'Oglio, Vione.
 * Val Trompia: Lumezzane, Sarezzo, Gardone Val Trompia, Villa Carcina, Marcheno, Bovegno, Collio, Caino, Lodrino, Pezzaze, Tavernole sul Mella, Marmentino, Irma.
 * Valle Sabbia: Gavardo, Vobarno, Prevalle, Villanuova sul Clisi, Roè Volciano, Vestone, Bagolino, Sabbio Chiese, Serle, Muscoline, Odolo, Paitone, Idro, Casto, Agnosine, Preseglie, Bione, Vallio Terme, Barghe, Provaglio Val Sabbia, Mura, Pertica Bassa, Lavenone, Pertica Alta, Treviso Bresciano, Anfo, Capovalle, Nuvolera, Nuvolento.
 * Lake Garda: Desenzano del Garda, Lonato del Garda, Gardone Riviera, Gargnano, Limone sul Garda, Manerba del Garda, Moniga del Garda, Padenghe sul Garda, Salò, San Felice del Benaco, Sirmione, Tignale, Toscolano Maderno, Tremosine, Soiano del Lago, Polpenazze del Garda, Calvagese della Riviera, Puegnago del Garda, Pozzolengo.
 * Bassa Bresciana: Montichiari, Ghedi, Chiari, Acquafredda, Bagnolo Mella, Bedizzole, Mazzano, Calcinato, Calvisano, Carpenedolo, Castenedolo, Fiesse, Flero, Gambara, Gottolengo, Isorella, Leno, Montirone, Poncarale, Remedello, Visano, Berlingo, Castelcovati, Castel Mella, Castrezzato, Comezzano-Cizzago, Maclodio, Orzinuovi, Orzivecchi, Pompiano, Pontoglio, Roccafranca, Rudiano, Travagliato, Trenzano, Urago d'Oglio, Villachiara, Ospitaletto, San Zeno Naviglio, Azzano Mella, Pavone del Mella, Capriano del Colle, Borgo San Giacomo, Cigole, Mairano, Dello, Pralboino, Verolanuova, Verolavecchia, San Gervasio Bresciano, Manerbio, Lograto, Quinzano d'Oglio, Pontevico, Longhena, Offlaga, Barbariga, Berlingo, Torbole Casaglia, Alfianello, San Paolo, Brandico, Seniga.

Municipal government
Here is a list of the municipal government in cities and towns with more than 15,000 inhabitants:

title: Province of Brescia


text:
MS Scandinavian Star

MS Scandinavian Star, originally named MS Massalia, was a car and passenger ferry built in France in 1971. The ship was set on fire on 7 April 1990, killing 159 people. The official investigation determined the fire had been caused by a convicted arsonist who died in the blaze. This finding has since been disputed.

After a lengthy period of lay-up after the fire, she was eventually repaired and refitted and put back into ferry service as the Regal Voyager, initially in the Mediterranean, and later in the Caribbean. She was eventually scrapped in 2004.

History
M/S Massalia was built by Dubigeon-Normandie SA in 1971 and delivered to Compagnie de Paquebots, which put her on the company's Marseille–Málaga–Casablanca route. The ship also conducted cruises in the Mediterranean Sea. By 1984 she had been owned by a number of companies and renamed Stena Baltica, Island Fiesta and finally Scandinavian Star, a name given to her by Scandinavian World Cruises. Scandinavian Star was chartered for cruises between St. Petersburg/Tampa, Florida, United States, to Cozumel, Quintana Roo, Mexico.

Scandinavian Star had been stricken by other fires throughout its history. During the investigation of the 1990 fire, investigators learned that unreported fires had also occurred in 1985, caused by a deep-fryer, and twice more in 1988, the first caused by a broken lubricating pipe. On 15 March 1988, just a few days after the first fire, Scandinavian Star was about 50 nmi northeast of Cancún when a second fire started in the engine room. The ship, which was then carrying 439 passengers and 268 crew members, lost its power supply and emergency oxygen system, hampering the fire crew's efforts. The inability of the crewmembers to communicate effectively with each other and with passengers was a serious concern and created confusion during the firefighting and evacuation procedures.

Fire
In 1990, Scandinavian Star was put into service on the Oslo-Frederikshavn route for the Norwegian shipping line DA-NO Linjen. As she had been converted from a casino ship to a passenger ferry, Scandinavian Star's new crew had to be trained in just ten days to learn new responsibilities, whereas six to eight weeks would have been a reasonable period to train a crew for a ship of its size. Many of the crew could not speak English, Norwegian or Danish, thus further reducing the effectiveness of the crew's response to an emergency. Erik Stein, technical leader for the Norwegian marine insurance company Assuranceforeningen Skuld, had inspected the ship and had declared the fire preparedness deficient, citing defective fire doors among other reasons.

During the night of 7 April 1990, at about 2 a.m. local time, a fire broke out and was discovered by a passenger and was brought to the attention of the receptionist. The fire spread from deck 3 to 4 stopping at deck 5. The stairwell and ceilings acted as chimneys for the fire to spread. Although the bulkheads were made of steel structure with asbestos wall boards, a melamine resin laminate was used as a decorative covering and proved extremely flammable in subsequent testing, spreading fire throughout deck 3. The burning laminates produced toxic hydrogen cyanide and carbon monoxide. The fire then spread to deck 4 and deck 5.

When the captain learned of the fire, he attempted to close the bulkhead fire doors on deck 3. The fire doors were not configured for fully automatic closing and did not respond since emergency alarms near the doors had not been manually triggered by passengers or crew. A vehicle storage area ventilated by large fans to remove exhaust fumes was also located nearby, and the fans pulled air through an improperly secured fire door and caused rapid fire progress from deck 3 through deck 4 and deck 5 via stairways located on either end.

The captain later ordered his crew to turn off the ventilation system when he realized it was feeding the fire, and an unintended result was that smoke was able to enter passenger cabins via the door vents. Some tried to seek refuge from the smoke in areas such as closets and bathrooms or remain asleep in bed, but were eventually overcome by smoke. Those who tried to escape may have variously encountered thick smoke, confusing corridor layouts, and poorly trained crew members.

Investigators proposed several reasons for why many passengers did not safely evacuate:

 * 1) Many people probably did not hear the alarms due to the distance between their cabins and the alarms, and due to the ordinary mechanical noise of the ship systems.
 * 2) Some people probably could not find their way out because of thick smoke obscuring the exit routes and signage.
 * 3) Burning melamine panels in the hallways produced poisonous hydrogen cyanide and carbon monoxide gases, causing rapid unconsciousness and death.
 * 4) Numerous Portuguese crew members did not speak or understand Norwegian, Danish or English, were unfamiliar with the ship, and had never practised a fire drill. Only a few crew members even thought to put on breathing masks before entering smoke-filled corridors.
 * 5) On deck 5, where most passenger deaths occurred, the hallways were arranged in a layout that contained dead ends and did not otherwise logically lead to emergency exits.

The captain ordered the general alarms to be activated, told everyone to abandon ship, and sent out a Mayday request. The captain and crew ultimately abandoned the ship before all passengers were evacuated, leaving many still on board the burning ship even after it was towed to the harbour. The ship was towed to Lysekil, Sweden, where the fire department suppressed the fire in ten hours.

Victims
The captain of the vessel said that the ferry was carrying 395 passengers and 97 crew on the day of the fire. It was later determined that 158 people, or approximately one-third of all passengers on board, died on the ship. Another victim died two weeks later from his injuries. 136 of those killed were Norwegian.

As many of the victims' remains were damaged by the fire, more than 100 specialists, including police technicians, forensic pathologists, and forensic dentists, worked to identify all the recovered remains. It was initially reported that many of the bodies found were children, but Swedish Police were quoted as stating that children under the age of 7 were not included on passenger lists, causing confusion on actual counts.

Investigation
An Oslo police investigation initially cast suspicion on Erik Mørk Andersen, a Danish truck driver who died in the disaster and who had three previous convictions for arson. A later investigation in 2009 determined that there were several separate fires and that multiple people would have been needed to start them, especially if they were not familiar with the layout of the ship. A 2013 report prepared by a self-appointed Norwegian group called "Stiftelsen Etterforskning Av Mordbrannen Scandinavian Star" ("Foundation for Arson Investigation Scandinavian Star") denied that Andersen was responsible, claiming instead that multiple fires were deliberately set and the truck driver was killed by one of the first two fires (up to nine hours prior to the last fire being started).

The same 2013 report claimed that as many as nine experienced members of the crew, having joined the ship earlier in Tampa, were likely to be responsible for six separate fires on the Scandinavian Star as well as multiple acts of sabotage to both the ship and the fire crew's efforts to put out the fire. The report proposed the motive for the crime was insurance fraud, as the ship was insured for twice its value shortly before the fire broke out. The report claims that multiple people with insider knowledge of the ship were required for events to unfold as they did. This controversial and unproven report led to renewed police interest, and in 2014 the investigation was officially reopened and charges dropped against the deceased suspect Andersen.

In March 2015, the Parliament of Norway decided to remove the statute of limitations for arson, such that criminal investigation and prosecution remains possible. In February 2016, the retired Danish investigator Flemming Thue Jensen, who had led the post-fire investigation in 1990, claimed that the fire was sabotage and was set by members of the ship's crew; that fire doors had been propped open to allow the fire to spread; and that a third flare-up that occurred after the ship had been evacuated of passengers was caused by crew members soaking mattresses with diesel fuel.

Changes to the International Code for Fire Safety Systems
The incident raised a number of issues relating to fire protection and evacuation on passenger ships. The International Code for Fire Safety Systems of the International Maritime Organization's International Convention for the Safety of Life at Sea was comprehensively amended after the disaster, in 1992.

Salvage and later service
The burnt ship was towed to Copenhagen, Denmark on 18 April 1990, arriving two days later and remaining there for several months. On 11 August 1990, she was towed to the United Kingdom, first arriving at Hull before moving on to Southampton on 10 September, where the vessel was renamed Candi by simply painting over part of the original name.

In February 1994, she was sold at auction to International Shipping Partners. She was renamed Regal Voyager and sent to Italy for rebuilding, then later chartered to Comarit Ferries and put on the route between Tangier, Morocco and Port-Vendres, France.

In 1997, she was registered to St. Thomas Cruises and put on a route between Port Isabel, Texas and Puerto Cortés, Honduras, for Isabel Cortes Ferry Service. Chartered to Ferries del Caribe in 1999, she was put on the route Santo Domingo – San Juan, Puerto Rico. The ship was laid up in Charleston, South Carolina in 2003, then sold to Indian shipbreakers in 2004 and renamed as Regal V. She arrived at Alang, Gujarat, India, on 14 May 2004, and the work to get her broken up started five days later.

Memorials
A few months after the fire, a two-day memorial voyage was arranged by a survivors' support group, clergymen and psychologists in order to remember the victims and help survivors and family members heal. The voyage was taken by about 300 people, who dropped flowers into the North Sea during a sunset memorial service.

On 7 April 2006, a memorial was inaugurated in Oslo, near the Akershus Fortress. It features a mother carrying her baby and leading another child, a small boy who reaches back for his dropped teddy bear; also a large commemorative plaque with the names of all the victims of the fire.

In 2015 on the 25th anniversary of the fire, Queen Sonja of Norway, Norwegian Prime Minister Erna Solberg, Oslo Mayor Fabian Stang, and Denmark's Ambassador to Norway Torben Brylle, paid tribute to the victims and survivors in a waterfront ceremony.

A permanent memorial of the Scandinavian Star fire was unveiled in Lysekil on 13 May 2021.

2020 documentary and possible reopening of the case
In 2020, Danish national television channel DR, Norwegian channel NRK, and Swedish channel TV4 broadcast a six-hour Nordic documentary named Scandinavian Star, largely based on Politiken journalist Lars Halskov's book Branden - Gåden om Scandinavian Star (The fire - The Scandinavian Star riddle). The documentary went into great detail and made a number of allegations about what happened that night, about why the truth of Scandinavian Star has never been revealed, how the authorities have let down the bereaved and how the police investigations into the matter are lacking.

Some of the allegations were:
 * Contrary to the authorities, several fire experts believe there were at least four fires that night and there was not just one fire propagating through the ship but rather individual fires started at different times. The fire experts point out that among the evidence to suggest this was the fact that the same section of the ship burned twice and that the Swedish firefighters maintain that all fires were put out while the ship was being towed to Lysekil, but still an enormous fire broke out in a completely different area of the ship five hours after the ship docked.
 * There is no evidence to suggest that Erik Mørk Andersen started any of the fires, and Andersen himself perished during the second fire.
 * Several fire experts and the Danish maritime authorities' main investigator, Flemming Thue Jensen, do not believe that the fires were the work of some random pyromaniac. They believe they were all started by professionals who knew what they were doing and knew the ship's layout well. When the second fire was started, two fire doors had been blocked to prevent them from closing, one with two mattresses and one with a big concrete block only accessible to the ship's crew. Keeping these fire doors open ensured quick fire propagation, because it ensured airflow from the car deck beneath the fire thereby ensuring a "wood stove effect", and the same fire was started in a position on the ship that allowed ventilation to carry it to other floors and to the opposite side of the ship.
 * Scandinavian Star was (officially) purchased by shipowner Henrik Johansen at a highly inflated price (US$21.7 million), and was immediately insured for US$24 million by Danish insurance company Fjerde Sø. Only one week earlier, the ship had been sold to SeaEscape Ltd. for just US$10 million. This may be an indicator of insurance fraud, but this has never been investigated properly by the authorities. A Swedish representative of Polferries, who had also been interested in purchasing the ship in 1990, said that Scandinavian Star was "a three-legged horse" and its value was not even close to US$20 million since it was old, poorly maintained and not a RO-RO ferry. The latter is a serious drawback for a ferry transporting vehicles, because they all have to reverse out the ferry when it arrives instead of just continuing forward out the other end of the ship.
 * On the morning of 7 April while the firefighters were trying to extinguish the flames, four members of the ship's crew were flown back to the ship by helicopter: the chief machinist, a machinist, the chief electrician and captain Hugo Larsen. They said they wanted to help the firefighters but the behaviour of the chief machinist and the chief electrician was highly suspicious. At one time, the chief electrician kicked wedges away from underneath the fire doors in an attempt to shut the doors. The firefighters had deliberately placed the wedges there for their own safety. Also, all four crew members disappeared at one time or another and the firefighters did not see them again.
 * According to several Swedish firefighters and salvage workers, three unknown men emerged from the ship during the night at Lysekil harbour and quickly disappeared before the firefighters could alert the police. Shortly thereafter, an enormous fire broke out in the ship's front restaurant area. This fire quickly rose to temperatures so high that firefighters were unable to put out the fire for another 12 hours. According to the fire brigade, there had been no previous fires anywhere near the restaurant.
 * Several large and suspicious fires had hit Scandinavian Star and her sister ships while they were sailing in the Caribbean. In 1984, a fire completely destroyed MS Scandinavian Sea and its value was written down to zero (thereby triggering payout of the full insurance sum).
 * Scandinavian Star was far from seaworthy when it started sailing with passengers on 1 April, and the safety of the passengers was given very low priority. While the ship was docked at Cuxhaven in Germany in March, an inspector for Norwegian insurance company, Skuld, inspected the ship and gave specific instructions that several things needed to be fixed before the ship could get a liability insurance, let alone travel with passengers. Among the defects were fire doors that did not close properly, rusty sprinkler systems that could not be tested, a critical fire door having been replaced by an ineffective glass door and that not a single fire drill had been conducted at any time. Strangely, Skuld ended up issuing a liability insurance for the ship anyway despite the inspector's report.
 * According to both Danish and Norwegian maritime authorities, none of them were informed in any way about Scandinavian Star, and therefore no inspection was conducted by any of them prior to 7 April. According to the Danish maritime authority, the ship was registered in Nassau, Bahamas and therefore only obliged to adhere to the much more lenient Bahamian safety regulations. However, in the documentary, former secretary and chairman of the Danish Association of Sailors, Henrik Berlau, alleged that the Danish maritime authorities knew that Scandinavian Star was not ready to transport passengers, before the ship was assigned to its route during the first week of April 1990. However, the maritime authorities opted to keep quiet about this after the disaster, because it might have rendered the state of Denmark liable for damages. Berlau states that his source is the former management of the maritime authorities and that the maritime authorities postponed their statutory inspection by two weeks. The ship burned before the inspection was scheduled. The maritime authorities have since commented on Berlau's information, stating that they have found no archival evidence to suggest that any employee had seen the ship or been in its presence.

On 9 May 2020, the documentary led to a majority of the Danish parliament voting to initiate a government hearing. Among the questions are: what is the status of the case, and what is being done to achieve closure?

title: MS Scandinavian Star


text: File:The Double Dream of Spring.jpg

title: File:The Double Dream of Spring.jpg


text: File:The Doobie Brothers - Stampede.jpg

title: File:The Doobie Brothers - Stampede.jpg


text:
Jets to Brazil

Jets to Brazil was an American indie rock band from Brooklyn, New York, US. They formed in 1997 and were active until 2003.

History
Jets to Brazil was founded by Blake Schwarzenbach, the former frontman of Jawbreaker, and Jeremy Chatelain, previously the guitarist and vocalist of Handsome, when Schwarzenbach relocated to New York City after Jawbreaker's disbanding. The two began working on four-track recordings aided by drum machines until former Texas Is the Reason drummer Chris Daly joined the band, and they signed to Jade Tree Records. The origin of the band's name came from a suggestion by Daly, after seeing it on a poster in the 1961 film Breakfast at Tiffany's.

The group's first album, Orange Rhyming Dictionary, was released on Jade Tree Records in 1998 to critical and commercial success, followed by extensive touring with bands like The Promise Ring. Their second album, Four Cornered Night, was released in 2000 to mainly positive reviews. Four Cornered Night was the first album to feature new guitarist Brian Maryansky, formerly of the band The Van Pelt. With Maryansky included in the band, this allowed Schwarzenbach to also become the keyboard player for the band. In 2002, Jets to Brazil released their third and final album, Perfecting Loneliness, to positive reviews.

By the fall of 2003, less than a year after the release of Perfecting Loneliness, the band broke up for unspecified reasons.

Schwarzenbach teaches English at Hunter College in New York City and is pursuing a PhD in English Literature. In October 2008, he started a new band, The Thorns of Life, but was short-lived and broke up in August 2009. Shortly afterwards, Schwarzenbach enlisted Against Me! drummer Kevin Mahon and bassist Caroline Paquita to form Forgetters who released an album and started their own record label, Too Small To Fail Records. In 2017, Schwarzenbach reunited with Jawbreaker.

Daly reunited with Texas Is The Reason for two shows at the Irving Plaza in New York City in November 2006 and a reunion tour from 2012 to 2013.

"Sweet Avenue", the final track of Orange Rhyming Dictionary, has often been attributed to Damien Rice due to misattribution on peer-to-peer networks.

On March 25, 2019, during the Q&A portion a screening of Jawbreaker's documentary Don't Break Down, Schwarzenbach answered a fan question regarding a Jets To Brazil reunion to which he answered it may happen one day but his present main focus is on Jawbreaker.

Members

 * Final line-up
 * Blake Schwarzenbach – lead vocals, guitars, piano, keyboards, mellotron (1997–2003)
 * Jeremy Chatelain – bass, backing vocals (1997–2003)
 * Chris Daly – drums, percussion (1997–2003)
 * Brian Maryansky – guitars (1998–2003)

 * Former members
 * Pete Martin – guitars (1997)

 * Studio contributors
 * Amy Domingues – cello (2000, 2002)
 * J. Robbins – guitars, backing vocals (1998) ; mellotron, sequencer (2002) ; Robbins was also the producer of all the band's albums.

Discography

 * Orange Rhyming Dictionary (1998)
 * Four Cornered Night (2000)
 * Perfecting Loneliness (2002)

title: Jets to Brazil


text:
Planum temporale

The planum temporale is the cortical area just posterior to the auditory cortex (Heschl's gyrus) within the Sylvian fissure. It is a triangular region which forms the heart of Wernicke's area, one of the most important functional areas for language. Original studies on this area found that the planum temporale was one of the most asymmetric regions in the brain, with this area being up to ten times larger in the left cerebral hemisphere than the right.

Location
The planum temporale makes up the superior surface of the superior temporal gyrus to the parietal lobe. The posterior extent of the planum temporale has been variably defined, which has led to disputes to estimates of size and degree of asymmetry.

Asymmetry
The planum temporale shows a significant asymmetry. In 65% of all individuals the left planum temporale appears to be more developed, while the right planum temporale is more developed in only 11%. In some people’s brains, the planum temporale is more than five times larger on the left than on the right, making it the most asymmetrical structure in the brain. Evidence for this asymmetry has also been seen in great apes.

This greater size of the left planum temporale compared with the right is already present in the fetus, where it can be observed starting from the 31st week of gestation. This observation strengthens the hypothesis of a genetic predisposition for brain asymmetry, however the effect of fetal experience has not been ruled out. Leftward asymmetry, however, does not directly relate to asymmetry of language processing in all individuals.

In addition, more and more research is suggesting that the apparent asymmetries in this region are the result of old techniques and criteria used to identify the planum temporale. When new imaging is used that takes into account asymmetries in the curvatures of lateral fissures, the hemispheric asymmetries of the planum temporale become negligible. This newer imaging would indicate that the size of the region would not explain the higher faculties of language in the left hemisphere, but would instead require an analysis of the neural circuitry.

Gender based asymmetry
Imaging has repeatedly suggested gender marked differences in planum temporale surface area asymmetry. There have been multiple findings suggesting a greater leftward surface area asymmetry in male subjects, with no significant difference as mediated by gender of the right part of the planum temporale.

Recent evidence can be used to support the idea that differences between males and females in planum temporale asymmetry begin to develop and show early in development, potentially during prenatal stages. Gender based asymmetry may be the result of environmental factors occurring in-utero, such as levels of testosterone.

Certain studies have found differences within the planum temporale on a microscopic level, finding greater cell packing density in females, as well as a reduction of micro-structural asymmetry. Females have also been found to display asymmetry in grey matter volume.

Due to the novel nature of these findings, researchers have yet to discern how to interpret these sex-based differences on brain function.

Functions
The planum temporale is a highly lateralized brain structure involved with language and with music. Although the planum temporale is found to have an asymmetry in the normal population, having a leftward bias in right-handed individuals, people who possess absolute pitch have an increased leftward asymmetry of the planum temporale. This is due to a smaller than average volume of the right planum temporale and not a larger than average volume of the left. The planum temporale may also play an important role in auditory processing with recent research suggesting that the region is responsible for representing the location of sounds in space.

There have also been many studies that show the asymmetry of the planum temporale to be related to handedness of subjects. There have been reports of decreased asymmetry displayed on the left side of the planum temporale in those that are dominantly left handed.

Atypical development
The planum temporale seems to be symmetrical in individuals with dyslexia, which may indicate that their low specialization in the left hemisphere is a cause of their disability. This symmetry also holds for people who stutter, although it is also possible to see a larger right planum temporale in stutters. It is thought that this bias for right hemisphere could be interrupting or impeding information flow between Wernickes and Broca's, which are on the left hemisphere.

MRI studies have shown that the planum temporale in schizophrenics is more symmetrical. This reduced lateralization correlates with more severe positive symptoms, such as hallucinations, as measured by the PANSS.

Sexual dimorphism has shown to play an important role on planum temporale studies within schizophrenia. These findings have highlighted the relevance and importance of sex/gender as a plays a key role on PT in schizophrenia, underlying the importance of gender as a key component of brain morphology and the specialized brain structure and function for schizophrenia.

Non-human brains
Although the brain area was thought to be unique to humans, almost like the anatomic version of the linguistic "language organ" of Noam Chomsky, it was shown to be similarly leftward asymmetric in chimpanzees and other great apes but not other primates, as was a related, rightward asymmetric, brain region the planum parietale that is implicated with dyslexia in humans. Monkeys show cellular asymmetry but not gross anatomic asymmetry of the planum temporale. (Brain Research, 2008). The question still remains open; what are great apes or monkeys using this "non-human primate language area" for?

title: Planum temporale