In my program the receiver has a bigger workload, should i make the sender wait for the receiver through methods like application level ACK?
You shouldn't directly send TCP ACK messages--those are handled at a low level by the OS. I'd look at the following in order of likelihood:
Is there some easy optimization on the receiver? It's pretty rare that you can really fill a network pipe more quickly than the receiver can handle the data. Make sure that the receiver has at least two threads: a network i/o thread and a work thread.
If the receiver is starting to panic, it could send a throttle message to the server, which makes the server cool its heels until the receiver catches up. This is more efficient than waiting for an ack message after every message, but it requires that the receiver know when it's about to fall behind, which might be difficult.
Alternately, the slowest but most reliable thing is to have the receiver acknowledge every message from the server, sort of like you mentioned. This wouldn't be a TCP ACK, but a special message in the data format that your sender/receiver are using for comm.
Related
On windows, say IO completion port is used to process tcp incoming packets. Now suppose all worker threads associated with the iocp is stuck, hence not processing any more receiving buffer of the tcp stack. Will this cause "Packets Received Discarded" counter to go up?
From experiment and wireshark capture, eventually receiver side signals [TCP Zero Window] and sender side stops sending. But I'm not sure if any discards happen before that.
I also didn't find any in depth, thorough description of what could cause "Packets Received Discarded".
I am chasing down a bug in my code that I think might have to do with a socket blocking on send. I'm working in C#, using the Socket class in blocking mode. I would love to be able to do some testing in my local environment to see what happens if the SendTo method blocks on send, but I am not sure if there is a way to do this on Windows.
What I am trying to do right now is to have two programs which I'm running locally. One sets up a UDP socket and then reads data very slowly (1 second delay between reads). The other program just sends a firehose of data to the first--one 63k datagram after another as fast as possible in an infinite loop. I was hoping that eventually some buffer somewhere would fill up and SendTo would block, but I am not having any luck.
Is my test fundamentally flawed, or is there some way to actually do this in Windows?
One other note: I am sending my packets on 127.0.0.1--do I actually need to have the packets routed out of my NIC for this to have any chance of working?
UDP is a datagram protocol for unreliable delivery. Your OS can just discard packets; there's no expectation of buffering. In fact, for applications like video streaming it's GOOD to discard packets, else you can end up with a lot of lag. UDP applications should detect lost packets themselves and adapt, e.g. by lowering the video resolution (or whatever makes sense for your type of application).
TCP is the reliable protocol. The OS will talk with the other OS to verify that all TCP data arrived. A slow reader also acknowledges the data slowly, which in turn slows down the sender. localhost simplifies this a bit, but for applications that doesn't really matter.
[edit]
Addressing your problem a bit more directly: since UDP doesn't care one iota about receiving data, you can just drop that receiver. That will loose 100% of the packets, but you were only wondering about the send part.
As for the buffering, you're right that localhost won't be effective. It's way too fast. The best approach might be to intentionally worsen your network connection. Perhaps your Ethernet can be forced to 100 Mbps? Perhaps an USB2 network adapter? UDP might be tolerant about losses, but if you run UDP over a VPN over TCP you suddenly get a bunch of slower software layers. Packets can now get lost after the VPN server, but any packets lost on the way to the VPN server need to be resent. And when that VPN connection runs over some bad WiFi, there's bound to be some packet loss.
I am told to increase TCP buffer size in order to process messages faster.
My Question is, no matter what buffer i am using for TCP message(ByteBuffer, DirectByteBuffer etc), whenever CPU receives interrupt from say NIC, to handle network request to read the socket data, does OS maintain any buffer in memory outside Address Space of requesting process(i.g. the process which is listening on that socket)
or
whatever way CPU receives network data, it will always be written in a buffer of process address space only and no buffer(including 'Recv-Q' and 'Send-Q' of netstat command) outside of the address space is maintained for this communication?
The process by which the Linux network stack receives data is a bit complicated. I wrote a comprehensive guide to the Linux network stack that explains everything you need to know starting from the device driver up to a userland program's socket receive queue.
There are many places buffers are maintained in the kernel:
The DMA ring where packets are written by the NIC after they've arrived.
References to the packets on the DMA ring are used to process the packet.
Eventually, the packet data is added to process' receive queue, if the receive queue is not full already.
Reads from the socket will pull packets from the process' receive queue.
If packet sniffing is occurring, packet data is duplicated and sent to any filters added by the packet sniffing code.
The full process of how data is moved, accounted for, and dropped (when required) is described in the blog post linked above.
Now, if you want to process messages faster, I assume you mean you want to reduce your packet processing latency, correct? If so, you should consider using SO_BUSYPOLL which can help reduce packet processing latency.
Increasing the receive buffer just increases the number of packets that can be queued for a userland socket. To increasing packet processing power, you need to carefully monitor and tune each component of the network stack. You may need to use something like RPS to increase the number of CPUs processing packets.
You will also want to monitor each component of your network stack to ensure that available buffers and CPU processing power is sufficient to handle your packet workload.
See:
http://linux.die.net/man/3/setsockopt
The options are SO_SNDBUF, and SO_RCVBUF. If you directly use the C-API, the call is setsockopt itself. If you use some kind of framework look up how to set socket options. This is indeed a kernel-side buffer, not one held by your process. It determines how many bytes the kernel can hold ready for you to fetch from a call to read/receive. It also affects the flow control mechanism of TCP.
You are being told to increase the socket send or receive buffer sizes. These are associated with the socket, in the TCP part of the kernel. See setsockopt() and SO_RCVBUF and SO_SNDBUF.
The UDP protocol does not guarantee packets being received sequentially, but you could just use part of the datagram for a sequence number.
Compared to the guarantee of TCP, is the above solution for UDP equivalent?
Basically, I've been reading everywhere that UDP does not provide sequential receiving, but this seems like such an obvious fix that I was wondering if it is truly an adequate fix.
The only 'disadvantage' is that you lose a few bytes of data space.
However, by itself, it isn't a solution. You have to add ACK messages into your protocol so that the sender knows what you have and haven't received; you have to buffer sent datagrams at the sender until they are ACK'd in case you have to retransmit then; and you have to either buffer out of sequence datagrams or throw them away so you can reconstruct the sequence correctly. Having come this far, it would also be sensible for the sender to implement some form of flow control or pacing if it notices a lot of retransmission being required.
This is a good way towards implementing TCP. Most people give up at this point and use TCP.
Using UDP in that fashion makes the application need to handle packet reconstruction and sequencing. That creates overhead in the application layer of the network. TCP is probably more efficient at handling that in the transport layer.
As well, UDP does not provide a mechanism for resending lost packets. When your application notices that the sequence numbers skipped one, there is some ambiguity in the meaning. Is there a lost packet or a delay packet? Your application would need to be able to detect that, and be able to request that the packet be sent again via a packet number reference.
In other words, there is a reason for the overhead of TCP when in-order guaranteed delivery is required.
https://en.wikipedia.org/wiki/User_Datagram_Protocol
It sounds like you want a form of partial reliability, inbetween TCP and UDP.
An option is to use SCTP-over-UDP (SCTP, portable userspace & kernel source). SCTP lets you set in-order for unreliable UDP-like streams , and also for partially-reliable streams (limited time or number of re-transmits)
.
Of course you could implement the missing features from TCP in UDP but that would destroy the purpose of UDP. The point is that the TCP implementation in your network stack peforms all the neccessary operations for you. (Involving packet reassembling and packet loss).
If you need TCP than you should use it. UDP is designed for packets where you don't care if they got lost (like VOIP, Gameserver, etc.).
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.