• Unfortunately, we have experienced significant hard drive damage that requires urgent maintenance and rebuilding. The forum will be a state of read only until we install our new drives and rebuild all the configurations needed. Please follow our Facebook page for updates, we will be back up shortly! (The forum could go offline at any given time due to the nature of the failed drives whilst awaiting the upgrades.) When you see an Incapsula error, you know we are in the process of migration.

Sockets & Packets

Skilled Illusionist
Joined
Jun 21, 2010
Messages
324
Reaction score
54
Hello!

I'm having a bit of trouble working with sockets and TCP connections with C#. The idea is this:

1. Server is listening for clients
2. Client requests connection, connection is accepted.
3. Client sends first packet (let's call that the hello packet)
4. Server sends a reply back to acknowledge the client
5. Server waits for a reply from client and writes the reply to the console.

I'm quite new to sockets in C#, however I really want to get into it. So far, I have everything working fine, apart from the fact, that I don't know how to send a second packet. If I repeat steps 3 and 4, the code eventually throws an error about not being able to read data from the transport connection.

I have a slight feeling that something needs to be cleared or something similar, but I don't know what it is.

If it helps, this server is accepting connections from a Habbo client.

This is code I have so far:
Code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using System.Net;
using System.Net.Sockets;

namespace Gingerbread
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Title = "Hello! Gingerbread";

            TcpListener server = null;
            try
            {
                IPAddress address = IPAddress.Parse("127.0.0.1");
                int port = 1337;

                server = new TcpListener(address, port);
                server.Start();

                byte[] bytes = new byte[256];
                string data = string.Empty;

                while (true)
                {
                    Console.WriteLine("Server successfully listening on {0}:{1}", address.ToString(), port);
                    TcpClient client = server.AcceptTcpClient();
                    Console.WriteLine("Connection from: {0}", client.Client.RemoteEndPoint.ToString());

                    data = null;

                    NetworkStream stream = client.GetStream();

                    // packet 1
                    // get xml policy request
                    int bytes_p1 = stream.Read(bytes, 0, bytes.Length);
                    data = Encoding.ASCII.GetString(bytes, 0, bytes_p1);
                    Console.WriteLine(data);

                    // reply 1
                    // send xml policy request
                    string reply = "<?xml version=\"1.0\"?>\r\n" + "<!DOCTYPE cross-domain-policy SYSTEM \"/xml/dtds/cross-domain-policy.dtd\">\r\n" + "<cross-domain-policy>\r\n" + "<allow-access-from domain=\"*\" to-ports=\"1-31111\" />\r\n" + "</cross-domain-policy>\x0";
                    byte[] msg = Encoding.ASCII.GetBytes(reply);
                    stream.Write(msg, 0, msg.Length);
                    stream.Flush();

                    // packet 2
                    // get unknown message
                    int bytes_p2 = stream.Read(bytes, 0, bytes.Length);
                    data = Encoding.ASCII.GetString(bytes, 0, bytes_p2);
                    Console.WriteLine(data);
                }
            }
            catch (SocketException e)
            {
                Console.WriteLine(e.Message);
            }
            finally
            {
                server.Stop();
            }

            Console.Read();
        }
    }
}
 
Elite Diviner
Joined
May 30, 2011
Messages
443
Reaction score
95
TCP is pretty much always represented as a stream, meaning there is no packet boundary or a defined end to the data. Probably what's happening is you're sending packet which the client doesn't like (e.g. sending a hello message twice or a malformed packet), it closes without telling your end why and then the next time you go to put another packet on the stream, it throws an exception when the TcpClient finds out the socket got closed. This makes it notoriously hard to debug network code. One thing you could do to debug it is wrap a StreamReader/StreamWriter pair around the NetworkStream and output all incoming and outgoing data to the console so you can manually verify that the right messages are being sent. It will also significantly simplify your code so you don't have to fill buffers and then convert to ASCII. If it's a totally text-based protocol, Stream[Reader|Writer] will make your life a lot easier. Other than that, there's no obvious reason for this code not to work -- it totally depends on the implementation of the client. The underlying socket might also have some SocketError information for you.
 
Skilled Illusionist
Joined
Jun 21, 2010
Messages
324
Reaction score
54
TCP is pretty much always represented as a stream, meaning there is no packet boundary or a defined end to the data. Probably what's happening is you're sending packet which the client doesn't like (e.g. sending a hello message twice or a malformed packet), it closes without telling your end why and then the next time you go to put another packet on the stream, it throws an exception when the TcpClient finds out the socket got closed. This makes it notoriously hard to debug network code. One thing you could do to debug it is wrap a StreamReader/StreamWriter pair around the NetworkStream and output all incoming and outgoing data to the console so you can manually verify that the right messages are being sent. It will also significantly simplify your code so you don't have to fill buffers and then convert to ASCII. If it's a totally text-based protocol, Stream[Reader|Writer] will make your life a lot easier. Other than that, there's no obvious reason for this code not to work -- it totally depends on the implementation of the client. The underlying socket might also have some SocketError information for you.

Thanks for the reply. No it's not text based, it has multiple encryptions/encodings. However, I believe the first two packets could be in plain text, however I could be wrong.
 
Back
Top