My question is that when a socket at the receiver-side sends an ack? At the time the application read the socket data or when the underlying layers get the data and put it in the buffer?
I want this because I want both side applications know whether the other side took the packet or not.
It's up to the operating system TCP stack when this happens, since TCP provides a stream to the application there's no guarenteed 1:1 correlation between the application doing read/writes and the packets sent on the wire and the TCP acks.
If you need to be assured the other side have received/processed your data, you need to build that into your application protocol - e.g. send a reply stating the data was received.
TCP ACKs are meant to acknowledge the TCP packets on the transmission layer not the application layer. Only your application can signal explicitly that it also has processed the data from the buffers.
TCP/IP (and therefor java sockets) will guarantee that you either successfully send the data OR get an error (exception in the case of java) eventually.
Related
I’m reading the article how TCP breaks application message into smaller parts (TCP segments) and use sequence and acknowledge numbers for interacting. In the article there is a example how is transmitting one application layer message within one TCP connection. So, I have a question. Can TCP transmit multiple application layer messages concurrently withing the same TCP connection.
In other words:
Creating TCP connection between client and server.
Client breaks message1 from application layer into TCP segments and start sending them
Client breaks message2 from application layer into TCP segments and start sending them
Client breaks message3 from application layer into TCP segments and start sending them
Step 2,3,4 are going in parallel withing the same TCP connection.
Server receives segments from message1, message2, message3 and send responses in parallel.
Is this possible somehow in TCP? Or we can transmit messages only consequently within the same TCP connection. I’m interested in TCP protocol itself, it doesn’t matter what tricks are used in application layer like multiplexing.
I’m reading the article how TCP breaks application message into smaller parts
TCP does not break application messages into smaller parts because there is no concept of an "application message" at the TCP level. From the perspective of TCP there is only a byte stream with no inherent semantics. Arbitrary splitting but also merging can be done at the byte stream for optimal transport. All what matters is that the bytes are delivered reliably, in order and without duplicates to the peer.
Any application which relies on TCP somehow maintaining message boundaries is broken - and StackOverflow is full of such examples and the problems caused by this.
Can TCP transmit multiple application layer messages concurrently withing the same TCP connection.
It is up to the application protocol and not TCP to implement such a behavior. For example HTTP/1 has only a concept of one message after the other - which clear protocol defined boundaries where messages start and end in the byte stream. In HTTP/2 messages can overlap though because HTTP/2 implements some kind of multiplexing inside the application protocol. But again - all of this is defined and implemented at the application layer and not at the transport layer (TCP).
This question asks what to do about loosing XMPP messages on mobile devices when they don't have a stable connection, but I don't really see why the packages get lost in the first place.
I remember having read that the stream between the server and the client stays open when the connection is suddenly lost and will only be destroyed once the connection times out. This means that the server sends arriving messages over the stream, even though the disconnected client can't receive those messages anymore.
I was happy with that explanation for some time, but started wondering why core XMPP would be lacking such an important feature. Eventually I noticed that ensuring correct transmission in the XMPP protocol would be redundant, as the underlying TCP should already ensure the proper transmission of the message, but as the various problems that arise from the lost message it seems that this isn't true.
Why isn't TCP enough to ensure that the message is either correctly sent or fails properly so the server knows it has to send the message later?
Why isn't TCP enough to ensure a proper transmission (or proper error handling, so the server knows the message has to be sent again) in this scenario?
Application gives the data that needs to be sent across to its TCP. TCP segments the data as needed and sends them out on established connection. Application passes over the burden of ensuring the packet reaches the other end to TCP. ( This does not mean,application should not have re-transmissions. Application level protocol can define re-send of messages if right response didn't come)
TCP has the mechanism of the Re-transmissions. Every packet sent to peer needs to be acknowledged. Until the acknowledgements come in TCP shall have the packets in its sendQ. Once the acknowledgement for the packets sent is received, they are removed.
If there is packet loss, acknowledgements don't arrive. TCP does the re-transmissions. Eventually gives up.Notifies application which needs to take action. Packet loss can happen beyond TCPs control. Thus TCP provides best-effort reliable service.
A newbie question: who exact send the ACK, the transport layer or the app? I have a COM-server with particle counters to send the data to my app. Sometimes I have a lost data. When I check the Wireshark protocol I see that the packets were sent from COM-Server but failed ACK from receiver. I think that ACK is missing because the my program has the error and can't edit the data properly. My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
TCP is a transport layer protocol. The ACK is part of TCP. Thus the ACK is part of the transport layer and send there.
Note that there might be apps which include the transport layer (i.e user space TCP implementations) in which case the ACK is send by the app, but not in the application layer but still in the transport layer. But in most cases TCP is implemented in the kernel and is thus outside the app. See OSI or TCP/IP model for more information about these layers.
My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
Assuming that you are not using a user space TCP implementation: The OS kernel will ACK the data as soon as these data are put into the socket buffer of your application. It will not ACK the packet if it failed to put it into the socket buffer, i.e. if the socket buffer is full because your application failed to read the data. In this case it will also reduce the window so that the peer will not send anymore data.
I was configuring IPtable yesterday. My colleague just asked me this question, and I couldn't anwser. I realized that I'm a much better developper than sysadmin and need to improve that.
So what are they? What are they for? Cons/Pros (if it's relevant).
These are like basic questions.
UDP :: User Datagram Protocol
1) No end to end Connection between to machines (may be in local network or somewhere in the internet).
2) The data received at the receiver end is not in stream as in TCP but as a complete block of data.
3) At the transport layer no packet order check is performed. That is in case of any error in the received packet, the receiver will not ask for resending the same packet to the sender.
4) Because of the above behaviour no sending buffers are required at the sender's end.
5) As no end to end connection is estld. and there are no handshakings required, UDP are pretty much faster but less reliable than TCP. Thus mostly used in gaming and DNS etc..
6) No acknowledgement required to be sent after recieiving packets.
TCP :: Transmission control Protocol
1) End to end Connection is maintained between to machines (may be in local network or somewhere in the internet).
2) The data received at the receiver end is a stream in TCP. Thus, when we do network programming for servers we first parse the header first and then depending upon the size mentioned in the header we obtain that much more number of bytes from the buffer.
3) Error checking and sequence number are all done. Thus in case any packet is received out of order (rarely) or is erred than that packet is made to resend. Also, lots of other protocols are involved for flow control (end to end flow control).
4) As connection establishment , handshaking and acknowledgement is to be done TCP are basically slower in operation than UDP.(Not significantly I believe)
5) Lots of protocols uses TCP as underlying transport protocol. HTTP,FTP,TELNET etc..
6) The communication procedure involves:
Server:: 1) Socket Open
2) Socket Bind
3) Socket Listen
4) Socket Accept
5) Socket Send/Recv
Client :: 1) Socket Open
2) Socket Connect
3) Socket Send/Recv
There are lots of other differeces also..but the above being the most common ones.
TCP is a reliable protocol which ensures that your packets reach their destination and is used in applications where all data must me trasfered accurately between parties. TCP requires both parties to negotiate a connection before data transfer can start and it is a resilient protocol since it will repeatedly resend a packet until that packet is received by the intended recipient.
UDP is unreliable in a sense that it allows some packets to be lost in transit. Some applications of UDP are found in movie streaming where you can actually afford to lose a frame and not jeopardize movie quality. UDP does not need binding between the two parties and is often looked at as a light alternative to TCP.
A nice table is found here:TCP vs UDP
P.R.'s answer is mostly correct, but incomplete.
TCP is a reliable, connected stream protocol. Its view of data is that of a bidirectional stream of bytes between hosts: whatever bytes you send will arrive at the other end in the same order, at least as far as the application is concerned (the OS will rearrange packets if needed).
UDP is an unconnected datagram protocol. Its view of data is that of discrete datagrams, or messages, with no guarantee that these messages actually reach their recipient, or that they arrive in the order they were sent. It does guarantee that if a message arrives, it arrives in its entirety and without modification.
This website probably offers the simplest explanation to the actual difference of UDP and TCP. From implementation point of view, see this question.
For short answer: TCP works kind of like registered letter when UDP is kind of like ordinary letter - with the latter you never know whether the recipient got the packet you sent.
There are loads of helpful comparisons
chris is right!
One fancy link dropping out of google is: http://www.skullbox.net/tcpudp.php
How does TCP/IP report errors when packet delivery fails permanently? All Socket.write() APIs I've seen simply pass bytes to the underlying TCP/IP output buffer and transfer the data asynchronously. How then is TCP/IP supposed to notify the developer if packet delivery fails permanently (i.e. the destination host is no longer reachable)?
Any protocol that requires the sender to wait for confirmation from the remote end will get an error message. But what happens for protocols where a sender doesn't have to read any bytes from the destination? Does TCP/IP just fail silently? Perhaps Socket.close() will return an error? Does the TCP/IP specification say anything about this?
TCP/IP is a reliable byte stream protocol. All your bytes will get to the receiver or you'll get an error indication.
The error indication will come in the form of a closed socket. Regardless of what the communication pattern (who does the sending), if the bytes can't be delivered, the socket will close.
So the question is, how do you see the socket close? If you're never reading, you'd eventually get an error trying to write to the closed socket (with ECONNRESET errno, I think).
If you have a need to sleep or wait for input on another file handle, you might want to do your waiting in a select() call where you include the socket in the list of sources you're waiting on (even if you never expect to receive anything). If the select() indicates that the socket is ready for a read call, you may get a -1 return (with ECONNRESET, I think). An EOF would indicate an orderly close (other side did a shutdown() or close().
How to distinguish this error close from a clean close (other program exiting, for example)? The errno values may be enough to distinguish error from orderly close.
If you want an unambiguous indication of a problem, you'll probably need to build some sort of application level protocol above the socket layer. For example, a short "ack" message sent by the receiver back to the sender. Then the violation of that higher level application protocol (sender didn't see an ack) would be a confirmation that it was an error close vs a clean close.
The sockets API has no way of informing the writer exactly how many bytes have been received as acknowledged by the peer. There are no guarantees made by the presence of a successful shutdown or close either.
The TCP/IP specification says nothing about the application interface (which is nearly always the sockets API).
SCTP is an alternative to TCP which attempts to address these shortcomings, among others.
In C, if you write to a socket that has failed with send(), you will get back the number of bytes that were sent. If this does not match the number of bytes you meant to send, then you have a problem. But also, when you write to a failed socket, you get SIGPIPE back. Before you start socket handling, you need to have a signal handler in place that will alert you when you get SIGPIPE.
If you are reading from a socket, you really should wrap it with an alarm so you can timeout. Like "alarm(timeout_val); recv(); alarm(0)". Check the return code of recv, and if it's 0, that indicates that the connection has been closed. A negative return result indicates a read failure and you need to check errno.
TCP is built upon the IP protocol, which is the centerpiece for the Internet, providing much of the interoperability that drives Routing, which is what determines how to get packets from their source to their destination. The IP protocol specifies that error messages should be sent back to the sender via Internet Control Message Protocol(ICMP) in the case of a packet failing to get to the sender. Some of these reasons include the Time To Live(TTL) field being decremented to zero, often meaning that the packet got stuck in a routing loop, or the packet getting dropped due to switch contention causing buffer overruns. As others have said, it is the responsibility of the Socket API that is being used to relay these errors at the IP layer up to the application interacting with the network at the TCP layer.
TCP/IP packets are either raw, UDP, or TCP. TCP requires each byte to be acked, and it will re-transmit bytes that are not acked in time. raw, and UDP are connectionless (aka best effort), so any lost packets (barring some ICMP cases, but many of these get filtered for security) are silently dropped. Upper layer protocols can add reliability, such as is done with some raw OSPF packets.