Develop Reference

Putty can connect to server but client cannot

I have a command line application that listens on an address ie. 192.168.1.89:8001. I also have a c# client application that uses a socket to communicate with the server. Both of these applications are running on the same machine and I am not able connect to the server.
When I try to input 192.168.1.89:8001 as the address for the client I get a "No connection could be made because the target machine actively refused it" error. However when I used putty to make a raw connection to that same address I was successfully able to communicate with the server. Any ideas why putty is able to connect but not the client?
The client is creating the socket like this
this.socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
socket.Connect(IPAddress.Parse(HostIP), Port);.

Get all clients which are connected to a remote server port

I want to get all clients which are connected to a server port (i.e. port 80).
If I connect to the remote port using:
IPEndPoint endPoint = new IPEndPoint(ip, port);
Socket tcpSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
tcpSocket.Connect(endPoint);
I get as LocalEndPoint the ipaddress of the current client. How can I get the ip addresses of all clients which are connected to this port on the remote machine (or at least the count of connected clients)? I don't want to invoke the remote system.
Thanks for any help.
Harald

You can't. That's how sockets work and security is done. Once you have a connection between server and client, you can't get information about other clients.
You can change remote server code and alter protocol to add handling for your request so server will return number of connected clients. But that will require you to support that in protocol and alter TCP server implementation. Event that part can be tricky (calculate number of connected clients), because of half-closed connections, timeouts etc.

Tcp Listener and Client listening to specfic ip

What i am trying to do is listen to a socket of 5000, which works perfectly with the code
TcpListener listener = new TcpListener(IPAddress.Any, 5000);
NetworkStream Network;
TcpClient client;
client = listener.AcceptTcpClient();
but when the server has two clients that connect to the server they both listen to the same message coming through as they are multi threaded, i dont want this to happen because with them reading each other they are removing bytes from the network stream.
so my question is, is there a way for the listener to listen to any ip until it finally receives a connection, then once the connection has been made the thread only listens to that ip address??
Thank you

TCP does not work that way.
When you create a TCP socket, bind to port A, and listen what you have is :
A listening socket on port A
A client connects to the server, what happens is that the listening socket is cloned, the clone is part of a socket pair, the other socket is the connecting socket. The 'cloned' socket is called the servicing socket. End result :
A listening socket on port A (still lives, you did not close it)
A servicing socket on port A, but part of a socket pair. (IPA(A), IPB(B))
The socket pair identifies the connection! When something is received at TCP level, the source ip address and port are also checked and as such the right servicing socket is identified where upon the reception will take place.
You never ever receive data on a listening socket.
If another client connects you get this, assuming a different ip address and port:
A listening socket on port A (still lives, you did not close it)
A servicing socket on port A, but part of a socket pair. (IPA(A), IPB(B))
A servicing socket on port A, but part of a socket pair. (IPA(A), IPC(C))
and this is assuming that no connections are closed. You see now you have 3 sockets on your server system, all using the same port. 1 listening socket, and a servicing socket per connection that is being establised. ie per client. Each connection is distinct, the right socket will receive data that belongs to the connection. There are only 2 ends in a connection, and connections are bidirectional.
TCP is a bit complex, you may find my explanation daunting in which case you should try to read more about TCP in books, or on the internet. Also socket programming is an interesting read because a mere explanation of TCP does not explain what happens at socket level.

Can´t open a socket connection from J2ME to a C# server

I´m trying to open a tcp socket from a j2me midlet on a symbian device to a windows (C#) socket server. The server is working and was tested for months.
Now when I try to open a socket from the midlet
clientSocketConnection = (SocketConnection) Connector.open("socket://" + ip + ":" + port);
it just times out with a -34 error (Could not connect).
I know the phone has network capabilities and permissions as I can open such socket connections between 2 phones (emulated) using "ServerSocket" on one side and in the same machine the server is on.
Somehow the J2ME Socket is not compatible with the C# counterpart....
listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
Any hint on this matter would be really appreciated.
Also, should I use another type of socket on the server side? I could not find information about the AdressFamily, SocketType nor ProtocolType for the J2ME sockets.
Adding info due to the recent comments.
It´s not a firewall problem as I have no firewall and DMZ is configured for the machine ip.
The phone (emulated) has access to internet and when I open a socket from an emulator to another, both on the same machine, using my WAN PUBLIC ip on the "client" side to find the "server" side it works.

Well it´s solved now.
Really weird but binding a j2me listening port (ServerPort) on "localhost" it´s not the same as binding a .net listening port on "localhost".
I mean, when I made a "server" midlet listening on localhost the clients could connect, but when I did it on the .net server they couldn´t.
The "solution" was to hardcore the computer ip instead of using "localhost". I really do not understand why, but this worked...

Socket programming: The Server

Ok so I've been trying to teach myself some socket programming. I wrote myself a little C# application with an async server and I understand most of it, except for the following:
So the server has a port it listens on for connections then when it receives a connection it creates a different socket to do the communication on. This it what I dont understand... How does the communication happen between the client and the server when in theory the client has no idea what port has been elected for this new connection?
Thanks for all your answers
Edit: As far as I understand the listening thread listens on the default port, but all messages are then handled on a different socket for each client?
Edit Again: Some how you guys are misunderstanding my question. I understand normal socket communication. My problem is with an async server where the listening socket is different from the connecting socket. Ie.
Server listens on default port
Client attrmpts to connect.
Server receiver request.
Server then creates a communication socket between client
and server and continues listening
on the default port.
My problem is at the last step. How does the client now know how to communicate on the new socket?
Here is some sample code
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx

Although this question was posted over a year ago, I belive it is worth trying to clarify (or confuse?) it a bit more.
"How does the client now know how to communicate on the new socket?" - The client is not aware that a new socket was created. It simply keeps on sending data (packets) to the same port.
However, this gives rise to another question: How does the server know which data comes from which client? - Thanks to the TCP and IP protocols the server knows both the address of the client and the source port from which the packets were sent. With this information the server can receive packets from multiple clients and multiple (client) ports and route them to the correct socket. For this question, think of server sockets as filters: when packets are received from client X - port Y then route them to socket Z.
"...does it now know it needs to communicate on a different socket/port?" - This is a frequent source of confusion. When a new socket is created on the server to receive packets (after the connection has been established) it does not use a new port, it keeps on using the original port number. The entire socket creation process on the server side is transparent to the client. The client never knows (nor does it need to know) that a new socket was created to handle its packets.
Google TCP header for more information.
Hope this helps someone.

When the client connects to the server, it selects the port to connect to. The client also includes a port that it will receive responses on. This is typically a randomly selected port, but it's possible for the client to override that.
Think of it like a phone call. When you call someone, there is the phone number you call, and you also have a phone number. even though you both talk to each other, both phone numbers are in use.
That's not a perfect analogy, since phone numbers are more like IP addresses and trunk lines need not have an originating phone number in all cases, but the same concept applies.
Simply put, the TCP protocol requires an originating port and destination port as well as originating ip address and destination IP. When packets are sent in either direction, the apropriate IP/Port is used either way.

Actually the new connection use the same port. A server listen on a specific port for incoming connection, anytime it receives connection request from client, the server accept it and create a new thread to process the request. And then continue to listen on that port.

Definitions
Client: The socket at the remote machine that is connecting to the server
Server: The socket that is waiting for connections on the server
ServerClient: The socket which is communicating with the Client
Answer
I couldn't find any details about how the ServerClient port is transfered to the Client after the Server has accepted it. But it's most likely transfered in the handshake. Feel free to read RFC793 if you want to know more.
I wont go through the details, but you can read about passive connects to get more information about how listener sockets work at lower levels. But basically the purpose of listener sockets (Server) is only to accept sockets (ServerClient).
The port that the ServerClient uses is assigned by the socket implementation in the operating system and is nothing that you can control. All you need to know is that the each connected ServerClient will get it's own port and it's transfered to the Client during the (threeway) handskake (I think ;))