Most IRC servers have a concept known as SendQ and RecvQ. This is a concept which is not usually described in any detail by developers, it is just assumed that users and admins know what SendQ and RecvQ are. Because of this, we will attempt to explain the meaning of these two values.
Imagine that data on IRC is represented as water. When you send data to the IRC server, you turn on a tap, and water flows into the IRC server. When the IRC server sends data to you, the IRC server turns on its tap, and data flows to you.
Now this obviously means there must be two pipes, or channels, one to send and one to receive. It also stands to reason that you might send so much data to the server, or it might send so much data to you, that their pipe will burst, spraying water all over the place and generally making a mess.
To solve this problem, imagine that on the receiving end of each pipe, we place a resivoir, for example a barrel. We'll call the barrel on your end 'SendQ', and the barrel on the servers end 'RecvQ', because, the 'SendQ' barrel holds what youve been sent and the 'RecvQ' barrel holds what the server has received.
Now, imagine that each bucket has a tap on the bottom. As the server or your client processes the data, it empties water out of its bucket, we can assume that this data is safely discarded.
The idea of 'flooding' fits in quite well into this analogy, because, if we send too much data before the other end can empty its barrel… Yes, you guessed it, the barrel overflows. If we really were using buckets and water, you'd end up with a wet server, or a wet user Image:Tongue.gif. Because this is only an analogy, you get disconnected instead.
So, from this we can summize that the values you give to 'SendQ' and 'RecvQ' indicate the size of the barrels, how much water they may hold. Its safe to assume that in most situations, a server will send more to a client than it will receive, so in most cases, the SendQ “barrel” will be probably four times larger than the RecvQ “barrel”. Its also safe to assume that the client should be given some slack, so the RecvQ barrel should not be too small, or they will flood off the moment they try and send data. It should also not be too big, otherwise your server may end up completely full of water (in reality, it may run out of memory or spare CPU cycles).