I am trying to make a peer to peer chat program. the scenario is much more complicated but I will simplify it to get help in the the part where its needed.
as a summary:
A- The Server
There is a server waiting for clients to connect, when a client connects it will be kept as waiting till the next client connects.
When the 2nd client connects to the server the server will return to each client the ip and the port of the other client, so both client can talk to each other without intervention of the server.
Then the server back to 1
B- The client
the client start a tcpClient connection with server.
wait the server response.
client receive a custom object that contain the ip and the port of
the other client
start chatting with the other client using the ip:port provided by
the server of the other client.
The question is: is this possible considering network and firewall security configuration (default) on the client machine?
The client might be behind pating or nating router.
The application is going to run on the internet or local network.
Note: the thing i need help is it possible in C# to implemented the client part of the application to act as server and listen to a port and receive connections knowing that the port is not configured on the possible front end router;
Are there alternative solutions? The main idea is to keep the server out of the picture after server step 2
Related
This is my first foray into socket programming. I need some help to get started. Basically, I have a server that sends out status updates on a specific TCP port. I need a client computer to look out for those update messages. I've decided to create a Windows Service in C# that will be installed on the client computer. I can't figure out if the service should be TCP listener (server) or client. Any guidance will be highly appreciated.
Since you already have a server that will send the updates, all you need to do to receive these updates is to create a TCP client on your host. This will serve as the listener, just connect it to the appropriate server's IP and port. Alternatively if you already have a client that connects to the server and just want to intercept the traffic, use something like tcpdump.
Figured it out. This comment from TcpClient Class threw me off:
// Note, for this client to work you need to have a TcpServer
// connected to the same address as specified by the server, port
// combination.
I have created a windows service server program in c# which will receive data messages from a serial port and then send those messages to any clients that have connected to the server. I have also developed the client program (windows form) in c#.
Originally the server program was developed as a console application to make development easier. While running the server as a console application the connections to the clients worked well, I could run a client on the same PC as the server and also connect a client on a laptop connected to the same network.
The connection method is:
-client starts up
-client broadcasts (udp) to a specific port
-server responds to the UDP broadcast
-client initiates a TCP connection with the server using the IP address obtained from the UDP response
Since changing the server from a console application to a windows service I can no longer connect the client program running on the laptop to the server using this method. The client program running on the same machine as the server connects successfully. Can anyone offer some advice on what to investigate?
To solve the issue I was having I added a new rule in the firewall settings of the machine running the server service application. I allowed the port used on incoming connections and this solved the problem for me.
I also changed the network discovery procedure:
Server broadcasts every second to a port (UDP)
Client awaits the broadcast packet from the server
Client establishes a TCP connection with the server using the IP address obtained from the broadcast packet
I have a few questions regarding sockets, I searched but couldn't find a direct answer.
I have a login server, and a world server. I connect from the TcpClient to the TcpListener on the login server. I want both a Tcp and a Udp connection on the world server, so once login has been checked, I redirect the TcpClient to the world server using TcpClient.Connect.
After this process, I tell the client to connect via Udp to the login server, and then use Socket.Connect to forward again to the world server.
The reason I'm forwarding and not sending client messages to the client to redirect, is that I only want to expose the login server IP and port to the client.
I'm not experienced with sockets, is there a better way to redirect without exposing the world server IP and port?
You can check the image on this page: http://next-gen.cc/
What you are looking for is a connection server that will maintain one connection to a client socket and keep the state of the client (connected, authenticated, playing, disconnected).
Once the player logs in, the connection server opens its own socket to the right game server and forwards all messages there, also when a game server wants to send the client data it will send it to the connection server which in turn sends it to the client.
In other words, make your login/connection server function as a router between the client and your game world.
I have a question concerning communication between a server and a client using UDP. I'll first explain what I'm trying to do.
The client sends a message to the server using a random UDP source
port to a static server UDP port (11000).
The server then learns the clients sending port.
Then the server sends a message back to the client using another
random port to the clients sending port.
The problem is that the server can only send back if clients random port is forwarded on the router. I don't know if it's possible but shouldn't the server be able to send back to the the client using the same port the client used to send without forwarding the port? I also read about hole punching but if I understand correctly it's only needed when you want peer-to-peer connection. The server had a static ip. I'm trying this in C#.
I hope the question is clear. Thanks in advance!
EDIT: Information about the setup:
The client is a game client which should be able to connect to the server from almost any location. (It's currently running on my home pc). The server is located at school and has a static IP. All ports on the server are open and the server is also used for ftp and has a server running that uses TCP. Those things work fine. TCP works because it creates a connection and the server uses that connection to send back to the client. The problem with UDP is that the server can't send back to the client because UDP is connectionless.
Like I said if I open ports on the client everything works great. But my question is: How do I send back to the client without opening ports on the client? Most games don't require you to open ports. So is there any possibility to either send back without port forwarding or can I open a port using C#?
EDIT2: Found the answer
I found the answer. To communicate you need to use the same UdpClient to both send and receive. I was using one to send and one to receive.
Degor
I'm a little confused when it comes to socket servers in terms of deploying it online.
Running locally is fine as most tutorials get you to make a server application and a client application which I can execute. Done all that for awhile now and I'm happy with it but now I want to try it using a web host.
How would I deploy the socket server to my web host and then run the server? do I just upload the program to the server and run www.mywebpage.com/mysocketserver (assuming the program is called mysocketserver.exe)
may sound like a stupid question but I'm having one of those brain dead moments.
[Edit]
Great answers guys thank you. Shame I can only mark one as the answer.
Most hosting services are website related: you upload your website to their server and the host takes care of provisioning the application.
However you haven't written a website that is served by a web server, but a socket server, which is more akin to the web server itself that runs a website.
As a result you will need a host that will allow you to install and run applications, such as a Virtual Private Server service, rent a physical server or use a cloud service such as Amazon EC2.
You usually Remote Desktop or SSH into the server you are renting (or own) to upload and start the application either as a normal application, a Service or a Daemon.
Once you have installed your socket server on the host server and started the application running you should be able to contact your service using the IP address for your server and the port that you are running your socket server on.
For example, if your ip address is 10.0.0.1 and you've written your socket server to listen on port 1234, you should be able to contact your service at address 10.0.0.1:1234.
Take into account firewalls allowing access to that port.
You will also then be able to use a DNS service such as DynDns to assign a domain name to that ip address.
You can't do that unless your socket server is using HTTP as a protocol.
You are using a port for your server, right? The ports are used to identify which application to talk with.
When you browse the web using "http://something" you really say let me get the stuff which can be found on the IP 1.2.3.4 (DNS lookup) using port 80 (which is registered for HTTP). You don't have to specify the port in the browser since all browsers know that HTTP uses port 80.
So what you are really should do is to put the socket server on your host and tell your customers/users that they can connect to your socket server at port XXX on host "www.mywebpage.com".
If you've built a client you'll just hard code the port in it or specify the default port automatically.
The problem in the Internet is the routing/name translation, so that mywebpage gets translated into the correct IP address.
Either your webserver needs a fixed public IP address or you need to use a service like dynds which will dynamically map your changing IP address to the static name.