I just want to check my understanding of terms,I was stuck at the term "Connection-oriented".In case of virtual circuits which works at layer 3,connection establishment is nothing but reservation of resources like buffers.and it identifies path by combination of (VPI and VCI).I was under impression that term "connection oriented" means same in case of TCP which works at transport layer and does 3 way handshake for connection establishment. But after reading https://networkengineering.stackexchange.com/questions/6307/does-tcp-use-virtual-circuit-model
which mentions "But TCP connections still aren't circuits, because they don't reserve bandwidth during connection on every switch between the two nodes." I am confused.Am i missing some important terminology or concept?Thanks in advance.
In case of TCP, 'connection-oriented service' means having a session established in the transport layer. In case of TCP, data transmission is guaranteed. You have acknowledgements in TCP. These are some reasons why it is called 'connection-oriented'.
Related
Please bear the naivity of this question as I have close to no knowledge of networking. Please help me understand this thing more clearly.
Suppose, there is a river and people from both the ends needs to travel back and forth from one end to another. So a bridge can act as connection between both ends, Till the time, bridge is alive, The connection is said to be alive and travelling is possible. I want to know what does it mean to keep a TCP connection alive and what is exactly kept alive? As in case of river, bridge was kept alive.
Contrary to a bridge a TCP connection is not a physical thing but only a logical association between to ends. Data get delivered between the ends hop by hop through several intermediate systems. Single packets might get lost on the way or even the other end or some intermediate systems might crash so that connectivity is lost completely.
As long as regular data exchange is done between the ends such conditions can quickly be detected. If one end sends data the other has to acknowledge these - if the acknowledgement is missing the packet gets retransmitted. If data are still not acknowledged after retransmissions the connection is considered broken.
But the ends might not continuously exchange data. If the connection is idle (i.e. no data exchange) then it will not be detected that something got broken. TCP keep alive works around this problem by regularly exchanging packets on idle connections and expecting an acknowledgment. These are packets with no data payload since no data are there to be transmitted.
In both these end-points, some data (or state variables) needs to be associated with each connection which is necessary to execute TCP protocol. E.g., sender needs to remember sequence numbers, maintain copies of all sent/but not acknowledged packets. Receiver needs to track sequence numbers too, store copies of packets that are out of order, and reconstruct original stream from received packets. These state data structures are created (i.e., memory is allocated) when the connection is established, and are destroyed (memory is freed) when the connection is terminated (e.g., after exchanging FINs). This state is accociated with each open TCP socket. A good practice is not to have connections open forever without exchanging data (e.g., if one of the communication partners has crashed, it won't be able to do proper connection termination), so if the connection is idle for a long period (which i don't know exactly) it is reasonable that the socket is closed. The concept is known as "soft state", which basically means that each state (memory) has an expiration inactivity time untill it is deleted. If the socket is closed, then when new data has to be sent, new connection has to be established. Yes it does involve sending packets, but it has overhead of sending TCP packets without any payload for one RTT, before the first data is sent.
In theory TCP connection exists only on end-points of the connection. In practice, however, there are also many kinds of so called "middleboxes", which is a general name for network device that is not a router or a switch. These middleboxes sometimes also need to maintain state accociated with each TCP connections, so these keepalives will also refresh the state on these middleboxes.
But in both cases, these keepalives basically tell to reset inactivity timer associate with state for this connection.
What is the need of error control at data link layer when Transport layer provides error control ? What is the difference between the two error controls ?
Transport layer data could be broken down to many data-link layer frames/packets.
So it is possible that even without any data-link errors the transport layer stream/packet may be corrupt. Edit: This is because a transport layer path is usually composed of many data-link layer hops, for example:
Host1 <----> switch1 <----> switch2 <----> Host2
if a packet was lost between switch1 and switch2 then there would be no errors recorded on the switch2 Host2 link, but the corresponding transport layer stream would be corrupted.
On the other hand - once a data-link error is encountered it's possible to drop/restart the transport-layer transmission, without wasting resources.
This is because Data link layer deals exclusively with bit-level error correction. It takes a packet the receiving computer already has in its possession and determines if an error occurred in transmission and whether the data is intact or corrupt. However, there need to be additional controls in place to make sure the system knows that all the packets are arriving. This is called end to end error control and is the responsibility of transport layer. Transport layer couldn't care less whether the data in the payload is good or bad. That's Data link's job. Transport only cares if it is getting every packet that it is supposed to, and whether or not there are arriving in the right order. It is the transport layer that detects the absence of packets or the corruption of packets that occurred on the transmission end before they arrived at the Data link layer.
For additional details, refer to
http://books.google.ca/books?id=9c1FpB8qZ8UC&pg=PA216&lpg=PA216&dq=why+error+detection+and+correction+both+in+transport+and+link+layer+?&source=bl&ots=RI7-DU8RO0&sig=0U5Z9AmKkx3m3TA71WfIe1uTeW0&hl=en&sa=X&ei=LbqPUsahOtDEqQHyvIHQCw&ved=0CDUQ6AEwAQ#v=onepage&q=why%20error%20detection%20and%20correction%20both%20in%20transport%20and%20link%20layer%20%3F&f=false
It really depends on the protocols rather than the layer, but assuming you mean TCP...
TCP's error detection is minimal and designed more as an integrity check than any kind of reliable error detection. The reason you don't see this is practice is that data-link layers such as Ethernet, PPP, FrameRelay, etc. have much, much more robust error detection algorithms and so there are virtually no transmission errors for the TCP protocol to detect.
If you had a different transport layer protocol with robust error detection then you wouldn't strictly need it at lower levels. There is benefit, largely performance and resource use related, to discarding errors as low in the stack as possible.
Note that errors can creep in above the transport layer due to ram glitches, etc, so if data is really, really important then you should include error checking right in your application.
Assuming the checksum was correct this result meant that the data was damaged in transit.
Furthermore, the damage took place not on the transmission links (where it would be caught by the CRC) but rather must have occurred in one of the intermediate systems (routers
and bridges) or the sending or receiving hosts.
http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf
Firstly, retransmission of packets from end-to-end is an expensive task and potentially takes a lot of time. Having these checks at each link reduces the "length" that the retransmitted packet has to travel. Consider a case when there is an error-prone link on the end-to-end path. This link will probably cause many packet drops, being that it is unreliable. If there wasn't any link layer reliability, the retransmission could only be handled by the transport layer protocol. Therefore, the malformed packet would have to reach its destination, send a NACK (or equivalent), and only then could the retransmission take place. On the other hand, if link layer has reliability built in the packet would be retransmitted immediately only on the unreliable link.
Secondly, link layer reliability relies on bit checks only, while transport layer reliability also utilizes sequencing and acknowledgments. Consider a case where the segment passed to the network layer needs to be fragmented because the MTU is too small. Link layer reliability will only check for the integrity of each individual fragment. If one fragment is lost, link layer may not raise an alarm. On the other hand, transport layer will because it expects all the fragmented packets.
Finally, link layer is not only carrying TCP and other transport layer protocols within its payload. Therefore, it is befitting to have reliability built in for protocols which do not have reliability built-in so that malformed payloads don't go up the stack.
In a noisy channel where the error rate is high, like wireless networks, the error correction is done at the datalink layer.
In robust networks where the error rate is low, like LANs, the error correction is done at the transport layer, so the retransmission cost is minimized.
I saw a large number of failed connections between two hosts on my intranet (call them client and server).
Using netstat on both machines, I see corresponding port numbers where the server end is in SYN_RECV state and the client is in SYN_SENT.
My interpretation is that the server has responded to the client’s SYN with a SYN,ACK but this packet has been lost. The handshake is disrupted, the socket connection is in an incomplete state, and I see the client time out after 20-45 seconds.
My question is, does TCP offer a way for the server to re-transmit the SYN,ACK after some interval? Is this a good or bad idea?
More system details if relevant: both ends RHEL5, ssh succeeds, ping loses 100%, traceroute succeeds. Client is built on OpenOrb (Java), server is Mico (C++).
SYN and FIN flags are considered part of the sequence space and are transmitted reliably (so, the answer to your immediate question is "yes, it does, by default").
However, I think you really want to dig a bit deeper, because:
If you have a large number of failed connections on the hosts on your intranet, this points to a problem in the network - normally you should have a low, if any, connections that are stuck in these states. Retransmissions would mean your connection will hiccup for 2,4,8,.. seconds (though not necessary - depends on the TCP stack. Nonetheless nothing pretty for the users).
I would advise to run tcpdump or wireshark on both hosts and trace where the loss of the packets happens - and fix it.
On older hardware, a frequent reason could be a duplex mismatch on some pair of the devices in the path (incorrectly autodetected, or incorrectly hardcoded). Some other reasons may be a problem with the driver, or a bad cable (not enough bad to cause complete outage, but bad enough to cause periodic blackouts).
Why is data not transferred during the 3rd part of TCP 3-way handshake?
e.g.
(A to B)SYN
(B to A)ACK+SYN
(A to B) ACK.... why cant data be transferred along with this ACK?
I've always believed it was to keep the session establishment phase separate from the data transfer phase so that no real data is transferred until both ends of the session have agreed on the sequence numbers and session options, especially since packets arriving may be from a totally different, previous, session that just happens to have the same endpoints.
However, on further investigation, I'm not entirely certain that transmitting data with the handshake packets is disallowed. The section on TCP connection establishment in my Internetworking with TCP/IP1 book contains the following snippet:
Because of the protocol design, it is possible to send data along with the initial sequence numbers in the handshake segments. In such cases, the TCP software must hold the data until the handshake completes. Once a connection has been established, the TCP software can release data being held and deliver it to a waiting application program quickly.
Since it's certainly possible to construct a TCP packet with SYN (or ACK) and data, this may well be allowed. I've never seen it happen in the wild but, then again, I've never seen a hairy-eared dwarf lemur in the wild either, though I'm assured they exist.
It may be that it's the sockets software that prevents data going out before the session is fully established but TCP appears to consider it valid. It appears you can send data with a SYN-ACK packet (phase 2 of the connection establishment) since you have the other end's sequence number and options. Likewise, sending data with the phase 3 ACK packet appears to be possible as well.
The reason the TCP software holds on to the data until the handshake is fully complete is probably due to the reason mentioned above - only once both ends have agreed on the sequence numbers can you be sure that the data is not from a previous session.
1 Internetworking with TCP/IP Volume 1 Principles, Protocols and Architecture, 3rd edition, Douglas E. Comer, ISBN 0-13-216987-8.
There are 3 different accept versions in winsock. Aside from the basic accept which is there for standard compliance, there's also AcceptEx which seems the most advanced version (due to it's overlapped io capabilities), and WSAAccept. The latter supports a condition callback, which as far as I understand, allows the rejection of connection requests before they're accepted (when the SO_CONDITIONAL_ACCEPT option is enabled). None of the other versions supports this functionality.
Since I prefer to use AcceptEx with overlapped io, I wonder how come this functionality is only available in the simpler version?
I don't know enough about the inner workings of TCP to tell wehter there's actually any difference between rejecting a connection before it has been accepted, and disconnecting a socket right after a connection has been established? And if there is, is there any way to mimic the WSAAccept functionality with AcceptEx?
Can someone shed some light over this issue?
When a connection is established, the remote end sends a packet with the SYN flag set. The server answers with a SYN,ACK packet, and after that the remote end sends an ACK packet, which may already contain data.
There are two ways to break a TCP connection from forming. The first is resetting the connection - this is the same as the common "connection refused" message seen when connecting to a port nobody is listening to. In this case, the original SYN packet is answered with a RST packet, which terminates the connection immediately and is stateless. If the SYN is resent, RST will be generated from every received SYN packet.
The second is closing the connection as soon as it has been formed. On the TCP level, there is no way to close the connection both ways immediately - the only thing you can say is that "I am not going to send any more data". This happens so that when the initial SYN, SYN,ACK, ACK exchange has finished, the server sends a FIN packet to the remote end. In most cases, telling the other end with FIN that "I am not going to send any more data" makes the other end close the connection as well, and send it's own FIN packet. A connection terminated this way isn't any different from a normal connection where no data was sent for some reason. This means that the normal state tracking for TCP connections and the lingering close states will persist, just like for normal connections.
Now, on the C API side, this looks a bit different. When calling listen() on a port, the OS starts accepting connections on that port. This means that is starts replying SYN,ACK packets to connections, regardless if the C code has called accept() yet. So, on the TCP side, it makes no difference whether the connection is somehow closed before or after accept. The only additional concern is that a listening socket has a backlog, which means the number of non-accepted connections it can have waiting, before it starts saying RST to the remote end.
However, on windows, the SO_CONDITIONAL_ACCEPT call allows the application to take control of the backlog queue. This means that the server will not answer anything to a SYN packet until the application does something with the connection. This means, that rejecting connections at this level can actually send RST packets to the network without creating state.
So, if you cannot get the SO_CONDITIONAL_ACCEPT functionality enabled somehow on the socket you are using AcceptEx on, it will show up differently to the network. However, not many places actually use the immediate RST functionality, so I would think the requirement for that must mean a very specialized system indeed. For most common use cases, accepting a socket and then closing it is the normal way to behave.
I can't comment on the Windows side of things but as far as TCP is concerned, rejecting a connection is a bit different than disconnecting from it.
For one, disconnecting from a connection means there were more resources already "consumed" (e.g. ports state maintained in Firewalls & end-points, forwarding capacity used in switches/routers etc.) in both the network and the hosts. Rejecting a connection is less resource intensive.