Jump to content

  • Log In with Google      Sign In   
  • Create Account

.NET IRC TCPClient read hang after 30-40 minutes


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 assainator   Members   -  Reputation: 681

Like
0Likes
Like

Posted 25 February 2014 - 03:47 AM

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);
    }
}

"What? It disintegrated. By definition, it cannot be fixed." - Gru - Dispicable me

"Dude, the world is only limited by your imagination" - Me


Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5303

Like
0Likes
Like

Posted 25 February 2014 - 10:39 AM

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.


enum Bool { True, False, FileNotFound };

#3 assainator   Members   -  Reputation: 681

Like
0Likes
Like

Posted 25 February 2014 - 11:22 AM

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?


"What? It disintegrated. By definition, it cannot be fixed." - Gru - Dispicable me

"Dude, the world is only limited by your imagination" - Me


#4 hplus0603   Moderators   -  Reputation: 5303

Like
0Likes
Like

Posted 25 February 2014 - 12:11 PM

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.
enum Bool { True, False, FileNotFound };

#5 assainator   Members   -  Reputation: 681

Like
0Likes
Like

Posted 26 February 2014 - 05:18 PM

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.


"What? It disintegrated. By definition, it cannot be fixed." - Gru - Dispicable me

"Dude, the world is only limited by your imagination" - Me





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS