I wrote messenger in c# with sockets, but i have little problem with ports. To clear comunication I have to open port on router which i use in my messenger. How to resolve this problem? Is method to automatic open default closed ports?
Thanks.
There are a couple things you can do.
The first is to change the programming of your application so that it uses the regular http port (80) for communication. This would allow your app to make outbound calls pretty much anywhere.
Alternatively you could use a high port number from 49152 through 65535. ( See Assigning TCP/IP Ports for In-House Application Use ).
However, depending on where you are deploying your application it is highly likely that all of those ports are blocked via firewalls; and neither will solve your problem
Most messenger type applications can't go direct due to firewall issues. For example, even if you use port 80, its likely the client machines have that port blocked for incoming TCP requests.
Instead they typically connect to a known public server. When one client wishes to connect to a different one, the server will route the message between the two clients. A very simplified look at this is: Client A sends a communication request to the server for Client B. Client B polls the server for messages, sees one and shows it on the desktop.
There are ways to keep the TCP connection alive between the clients and server in order to speed up communications; but that's the basics.
There are even ways for clients to directly talk to each other, when they determine that certain ports are open for communication or that proxy servers aren't going to interfere with the traffic. However, that's a little more advanced than a simple "answer" here can provide.
Related
Many questions relating to port 80 being used have answers saying that there are many programs that use it as their default port. This post mentions some: Skype, IIS, Apache...
Since only one application can listen on any one port at a time - How can that be? And if the answer is that that's only their default port - how will an application know it has to send information to a different port? For example - if iis will listen on port 81 because Skype is listening on 80 - how will anyone requesting a web page know to send the request to theip:81 as opposed to theip:80?
My goal is to have a robust way of setting up a connection between programs, when any hard coded port might fail due to some application already listening on it. The port will only need to be used once in order to communicate what dynamic port will be used for the rest of the session. This is a problem for both network connections and for connecting several applications on the same computer.
Registering with IANA is not always possible, and won't even necessarily solve the problem - someone might still be listening on a registered port. And obviously the solution of "hope for no collisions" - just doesn't cut it.
(I do understand that a connection has two sockets (and a protocol) and therefore one socket can have multiple connections. My question is about listening on a socket in order to establish the connection.)
What I would expect, is there to exist some service on the OS (Windows) that I could register my application with, and receive all incoming traffic with some signature - even if it's simply some magic string. Or perhaps some port where multiple applications can listen concurrently - and all would get every incoming message. But I haven't found anything like that so far.
How can that be? Simply...it's not. Only one application will listen on each port. – Adriano Repetti
Right. When Skype listens on those ports before I start my web-server, the server fails. It took me a while to find out why.
Only one app can listen on a socket in a sane way. The OS allows multiple apps to listen on the same port if you specify special options but that's insane. Accepted connections are then dispatched to different applications in an unspecified (i.e. random) way.
IIS can run multiple web-apps on the same port because it opens the port once in kernel mode and dispatches connections to its worker processes.
I do not believe it is ever possible for multiple sockets to listen on the same (TCP) port. If you try to bind a socket to a port that is already open, you will get an error.
I believe Skype gets around the problem you describe by using their own servers as a rendezvous point. The simple explanation being:
Alice starts her client, connects to the central server, and informs it of what port she is listening on.
Bob starts his client and likewise informs the central server.
Now, Alice wants to connect to Bob, but doesn't know which port to send packets to.
Alice will then query the central server for Bob's port number.
With this information, a direct connection is then established with Bob using that port.
The logic can of course extend to learning the other party's IP address as well as even obtaining public keys.
Note that there's actually a bit more involved with most modern peer-to-peer applications, Skype being no exception. The problem being that most computers are now behind at least one NAT router. Getting two devices each behind their own router to connect to each other is known as NAT traversal - the most common technique having a central coordinating server instruct both clients to simultaneously connect to each other. For more information on this, I recommend Steve Gibson's Security Now!, episode #42
on the port forwarding setup page i just put a comma and add an other port to open. it wont allow you to set up an additional rule with listen port 80 but it will allow you to trigger multiple ports with that one listen port
For TCP, you can only have one application listening on a single port
at one time. Now if you had 2 network cards or created a virtual
interface, you could have one application listen on the first IP and
the second one on the second IP using the same port number.
For UDP (Multicasts), multiple applications can subscribe to the same
port.
one application listening on a single port that's the reason why ports exist. To allow multiple applications to share the network without conflicts.
But there are ways to do what you requested:
You could write a master process, which possesses the port and notifies slave processes using some separation logic.
On Linux and BSD you can set up remapping rules that redirect packets from the visible port to different ones(such as listener app), again by using some separation logic(e.g. redirect according to network origin etc.).
Note: For TCP, you multiple applications can listen on the same socket by using SO_REUSEADDR option before binding but what this does is redirect the incoming connection to only one of the listeners.
I am wanting to send some data to a server from a client application to the server via port 5555. I don't have a window's server. My question is if I purchase a .Net Framework hosting service. Would I be able to connect the client application to this server. and could I do it by sending a Post. I am new to this, so excuse me if it doesn't entire make sense. but I am looking for just some little direction. If someone could explain what port 5555 is used for that would be great.
Most hosting provides will only allow incoming connections on the standard web ports (80 for unencrypted traffic/http and 443 for encrypted/https). Outgoing connections are less likely to be restricted, but it is not uncommon that only a few specific ports are open.
If you're developing a custom solution and you do not need a connection that allows you to continually send data back and forth, then a hosted solution will do fine. If you do need the live link or custom port numbers then you'll need to upgrade to a virtual managed server, which is essentially your own virtual copy of a Windows server. This costs more but allows you to listen on custom ports - essentially do as you please.
As for determining the specific use of a port, most networked applications have simply picked one or more numbers without much research. IANA maintains a list of protocols/applications/services and their associated port numbers, but being listed requires that an application is sent and approved.
Custom port for data exchange + tcp/ip has been identified to be very difficult across the Internet, due to firewalls/gateways everywhere.
Why not use REST web service or SOAP web service for data exchange? That has been proved to be a firewall friendly approach as it uses port 80 or 443.
The remote client is a desktop application running a windows.forms application. How do I have the server send the client a message, knowing the client's IP address?
Check out these tutorials:
Simple Threaded TCP Server
High Performance TCP/IP Server using C#.NET
Building a TCP/IP server using C#
and these books
TCP/IP Sockets in C#: Practical Guide for Programmers (The Practical Guides)
C# Network Programming
Although sockets is an option, you may want to consider using a higher level abstraction such as the one provided by WCF.
WCF's Duplex Services allows you to implement communication going both ways (client -> server) and (server -> client) with some flexibility on choosing transport and protocol.
A common way to do this is using sockets.
Basically you open up a communication channel to the remote client using TCP/IP and can send messages back and forth. Both sides must know about the other and must agree on a message format.
When using sockets, you communicate on a port. Several ports are reserved for (or at least typically used by) certain protocols. For example, HTTP uses port 80 by default. You will want to select a port not already in common use. Also be sure that any firewalls between both ends allow communication on that port.
It could largely depend on the existing protocol that is being used between the client and the server. If the server is HTTP, then the client could poll to see if there are messages. If the client is already using TCP/IP, then ideally the server can send a message to the client any time it needs to.
Also, keep in mind that opening a communication channel may essentially be one way (i.e. from the client to the server), depending on firewall configuration (such as NAT).
In general terms you do that by replying to a request of the client. If you don't have client requests, the distinction between servers and client becomes rather blurred.
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.
I made a remote engine for a game which must be able to works in P2P.
It perfectly works in LAN, but there's a problem when computers are behind router(s) and want to communicate through internet.
Is there any solution to this, which doesn't need to manipulate the router configuration?
Because since most of my gamers may not be very acknowledged in informatic, I'd like to solve this problem as easily as possible, without any intervention from them.
Thanks,
KiTe.
You need the client behind the router to initiate an OUTGOING connection. Once that's established you can have 2 way communication on it. This is why most P2P games have some sort of server to set up matches between clients. You can have each client establish a socket to the server and then connect them to each other.
There was an alternative called 'NAT hole punching' a while back, but I'm not sure how reliable that was.
This is what separates LogMeIn from VNC.
These days almost all home users are behind a form of NAT, macking it impossible in practice to set up real peer-to-peer communication as the application listenning port is unreachable from the net.
In theory there is UPnP which allows applications( running under elevated priviledges) to enable port forwarding dynamically on the home router (via Internet Gateway Device Protocol), but in practice this is so unreliable that I haven't seen any real use of it.
The most reliable solution is to have a central hub (your game server) that forwards packets between clients that initiate the connection from behind the NAT device. But that is a serious cost to you, as you'll need to cash out the cost of provisioning and operating this hubs which can be serious money, even with dynamic just-in-time solutions like EC2.
Update
Perhaps you can use the Codeplex UPnP NAT traveral project.