Trying to connect to remote IP "address is not valid in its context"

Started by
4 comments, last by hplus0603 16 years, 6 months ago
Hey, I was handed an assignment where I had to write a client/server chat application (very basic) however for some strange reason it is the clients who listen for a connection and the server connects to them via a specified IP and Port. This is my first time tackling network programming in C# and I decided to write a class library (so I could reuse it later) and the sending/receiving between the server/clients server works IF they are all on my local machine. Whenever I put the clients on a remote computer and try to listen it crashes giving me the exception "The requested address is not valid in its context". I googled it and found a similar problem but this particular programmer was using the TCPClient constructor that binded the connection to the local computer. I figured this might be my problem but all constructors I use seem to indicate that it's for remote access. Here's a snippet from the server bit:

public void addClient(IPEndPoint clientEP)
        {
            _server = new TcpClient();
            _server.Connect(clientEP.Address, clientEP.Port);

            if (_server.Connected)
            {
                _connectedClients.Add(_server);
            }

            _server = null;
        }



Here's the client:

        public void connect()
        {
            if (_serverPort != 0 && _serverIp != null)
            {
                _listener = new TcpListener(new IPEndPoint(_serverIp, _serverPort));
                _listener.Start();
                _connectedServer = _listener.AcceptTcpClient();
                _sr = new StreamReader(_connectedServer.GetStream());
                _listener.Stop();
            }
        }



I really appreciate any help.
Advertisement
I'm not familiar with the C# library, but you seem to have the functionality of the server and client mixed up. The server listens + accepts, the clients connect. Without those basic assumptions, your post and code is kinda incoherent.
The mix up is intentional since that's how the requirements for the project were specified. Basically the client waits for a connection and then the server specifies the IP+Port to connect to. It's not intuitive and I honestly don't understand why the assignment specifies for it to be coded that way...

edit:

I can see how the code can be hard to read on the server side. _server should be called _aClient since it represents a client to be added. Basically I create the connection to the client and store it in an arraylist of clients.
What the? How can a client wait for a connection?

Generally the server doesn't know anything about the client, so, how can the server tell an un-connected client where to connect to?

I must be missing something here.
That sounds backward.

Do you mean a server as a Online service (NAT introducer), and the client as the chat host? And other clients as peers connecting to the chat host and requesting the host address from the NAT introducer?

In that case, the clients can be registering themselves with the introducer, the introducer notifies the chat host that a new client wants to connect, and send the host the client's IP and connection info. Then the client waits for the server to initiate the connection.

But really, that's backwards :)

Everything is better with Metal.

Maybe that part of the assignment is like that because it means you can't use code straight off Google.

In the spec, is the server able to connect to more than one chat client? Do you specify one ip+port per client to connect? If so, that would make sense. If not, how does it turn into a chat "server."

Note that "server" means different things. In this case, the chat "server" is the bit that receives text from one chat client, and (presumably) forwards to all other clients. The only gnarl is that the chat server is not a TCP service, in the currently requested implementation. Uncommon, but not forbidden.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement