I've been trying to write an IRC bot in C# using a TCPClient. It connects and starts receiving commands, responding to the PING command with a PONG command. That's all.

However, for some reason it hangs after 30 to 40 minutes on the function to read the next line of data. I've inspected the PING and PONG messages using Wireshark and they look fine to me. The PONGs are also received by the server as I do see an ACK packet being received by my computer in Wireshark.

The weird thing is that it works absolutely fine for those 30 to 40 minutes. I suspect I'm doing something wrong with the StreamReader but after searching the web for a few days I'm stuck.

Would somebody be so kind as to look at my code? Thanks a lot in advance.

public class Bot
{
    private NetworkStream ns;
    private StreamReader reader;
    private StreamWriter writer;
    private Encoding enc;           // The encoding used.

    /// <summary>
    /// Initialize the bot.
    /// </summary>
    public Bot()
    {
        enc = new UTF8Encoding();
    }

    /// <summary>
    /// Connects the an IRC server.
    /// </summary>
    /// <param name="url">The url of the server.</param>
    /// <param name="port">The port to connect to.</param>
    /// <param name="user">The username to use.</param>
    /// <param name="nick">The nick to use.</param>
    /// <param name="realName">The users real name.</param>
    public void Connect(string url, ushort port, string user, string nick, string realName)
    {
        TcpClient client = new TcpClient();

        try
        {
            client.Connect(url, port);
        }
        catch (Exception ex)
        {
            throw new Exception("Could not connect to endpoint.", ex);
        }

        ns = client.GetStream();
        reader = new StreamReader(ns, enc);
        writer = new StreamWriter(ns, enc);
        writer.AutoFlush = true;

        Send("USER " + user + " 0 * :" + realName + "\r\n");
        Send("NICK " + nick + "\r\n");
    }

    /// <summary>
    /// Processes a command.
    /// </summary>
    /// <param name="command">The command to process.</param>
    public virtual void ProcessCommand(IRCCommand command)
    {
        if(command.Command == "PING")
        {
            Send("PONG :" + command.Parameters[0] + "\r\n");
        }
    }

    /// <summary>
    /// Receives and processes a command.
    /// </summary>
    public void ReceiveAndProcess()
    {
        string line = reader.ReadLine();

        if (!string.IsNullOrEmpty(line))
        {
            Console.WriteLine("raw : " + line);

            IRCCommand cmd = new IRCCommand();
            cmd.Parse(line);

            ProcessCommand(cmd);
        }
    }

    /// <summary>
    /// Sends a command to the irc server.
    /// </summary>
    /// <param name="ircCommand">The command to send.</param>
    protected void Send(string ircCommand)
    {
        Console.Write("sent: " + ircCommand);
        writer.Write(ircCommand);
    }
}

My guess is that you end up with a dropped packet and re-send, and at that point, the StreamReader doesn't see the newline in the way you expect it.

You could verify this behavior by either looking for a re-transmit or collapsed packet in Wireshark, or by replacing the StreamReader/StreamWriter with your own class that uses raw byte arrays.

My guess is that you end up with a dropped packet and re-send, and at that point, the StreamReader doesn't see the newline in the way you expect it.

You could verify this behavior by either looking for a re-transmit or collapsed packet in Wireshark, or by replacing the StreamReader/StreamWriter with your own class that uses raw byte arrays.

Thanks I'll try that. How can I detect a collapsed packet in Wireshark?

I think Wireshark can call out where there are dropped ACKs or re-transmits of parts of a stream. You'll have to look at the sequence numbers and the ACKs right before the stall happens.

I've done several runs and inspected the last few packets after each disconnect. Everything seemed to be in order, the sequence numbers check out fine. I've also seen a few re-transmits, but within 10 minutes of a disconnect. Guess I'm going to try and process the received bytes myself. See if that's the problem.