Because of a certain requirement i need to have a service listening on port 443 (an maybe 80) to coexist with IIS on a same windows 2008 server. Its possible to have a Windows Service Hosted WCF service to share port 80 with IIS but i was wondering if this is possible to do in a C++ service? I've read answers about similar questions like this, this and this but i still haven't got an appropriate answer.
Only one application may be bound to an ip-address/port-number pair. If a socket is bound to INADDR_ANY and some port, then no other application my bind to that port.
If you want two applications to receive data on a port, you need some kind of proxy that listens on the actual port, while the other programs listens on some other port or address that the proxy-server connects to.
Using a proxy seems to be the way that WCF handles port-sharing. Quote from this link:
When a net.tcp binding enables port sharing (by setting portSharingEnabled=true on the
transport binding element), it implicitly allows an external process (namely the
SMSvcHost.exe, which hosts the Net.TCP Port Sharing Service) to manage the TCP socket on
its behalf.
Related
I have a SNMP Manager written in C++ using the MG Soft SDK. Till now it only sends Get and receives Trap with IPv4. Now a second SNMP Agent shall be connected but this one has IPv6. Is it possible with one application to get a connection to one remote system with IPv4 and to another one with IPv6 at the same time with the same networkcard? or do I need 2 networkcards, one for IPv4 and the other for IPv6?
Yes, it is possible. You just need to open 2 separate connections from within your application - one using IPv4, the other using IPv6 (of course this requires you to implement support for both IPv4 and IPv6 protocols in your application).
It works the same way as if you wanted to open multiple IPv4 connections from within the same application.
For instace, web browsers open separate connections for separate webpages you visit. They, of course, can connect to one web server using IPv4, while at the same time being connected to another web server via IPv6.
I'm working on a server, which is listening on the port 80
I would like to enable both native and websocket clients to connect to my server.
It works only, if websockify runs at a different port, and forwards the trafic to the socket server.
Unfortunately websockify isn't well documented, and there are no tutorials available.
Where should I start, if I would like to create a single server only, which is listening on only one port, and accepts both websocket and native TCP sockets?
If your server is listening for connections on port 80, is it talking http? Because if not, don't be listening on port 80: Port 80 is well established as carrying http traffic.
Next - an ipaddress and port together are the unique identifiers of an endpoint. If a remote client connects to your server on port 80, other than the destination ip and port there is no other information that the networking layer has to identify which application, listening on port 80, deserves the packet. Given that provisioning multiple ip addresses is quite hard - impossible over a NAT - the only information thats really available to route the packet to the correct listener is the port. So you just can not have two applications listening on the same port.
Lastly websockets behave like native sockets, AFTER an initial HTTP negotiation. This means that, instead of using websocksify, you could teach your native server application to detect an attempt to connect by a websocket client and optionally perform the initial negotiation before going into 'native' mode.
Writing Websocket Servers gives a brief breakdown of what your native server would need to implement.
If you take a look of WebSocket, you will see that it's a protocol over TCP layer. Thus, your server socket can bind only once to the port 80 and it's up to you either you will use plain TCP, WebSocket or your custom protocol. There is no magic which enables switching from WebSocket to TCP and vice versa.
I have written a simple program with Linux (Cent OS 7.0) and C++. It is a very small server which sends back a string of characters to the client. But my problem is that I don't know how should I access that server using an IP address?
I have used Linux Socket Interface (Berkeley), and in the section which defines the address, my code does the following:
serverObject.
sin_family = AF_INET;
serverObject.sin_addr.
s_addr = htonl(INADDR_ANY);
serverObject.
sin_port = htonl(portNumber);
I use INADDR_ANY as my server's address which is defined in its definition as:
/* Address to accept any incoming messages. */
Now, how should I run the server, and then use my simple client program to send request to it. My simple client program accepts an IP address as it's destination address, this address should be the one destined toward to the server. How should I relate it then?
INADDR_ANY goes to specify that all active network interfaces in the system should be bound to. So if you're connected to more than one network, you'll be able to communicate with connections coming in from all of them. Most systems will usually have just one, though, and this still goes to say that if the IP bound to that interface happens to change, you'll still bind to that interface.
So, once you specify INADDR_ANY, you need to initiate connections according to the following rules:
If you're connecting from the same physical machine, the easiest thing would be to use the loopback interface (127.0.0.1). However, you can still do (2).
If you're connecting from another machine, you need to pick the accessible IP address of your server from that machine. As said above, if your server is only connected to one network, this will simply be the IP address of the server. Within an internal network this will often be something like 192.168.x.y, or 10.0.x.y—but it doesn't have to.
If you're connecting from a different network which uses a gateway to access your server, then you will need to set up port forwarding in the relevant routers so that when they receive connection to port X, they will know to internally transfer it to your server.
As a server programmer, you decide the port on which to listen, but not the address.
The internet address is provided by your internet provider, or 127.0.0.1 to test on your own machine.
There are plenty of web pages on internet that provide tools to tell you your current public address (search for What is my Ip).
Most of the "home" internet routers implement NAT: they have a single internet address and map them to many device, that carry the Port number to be changed (your port 80 become port (e.g.) 2345 for outside). To allows a client from outside your home to access your server, you are required to configure your router to map the server port, so for example your public port 80 map to your server port 80.
With that said, you should be able to connect your client to your server through an address and port.
If then you want to use a name (example.org) instead of an IP (93.184.216.34), a Domain Name Server is used. But that is another topic.
Usually I use some random port for my client-server applications in Delphi/C++ Builder. But, since I work in a building with a strong firewall policies I would like to use port 80 (TCP and/or UDP).
My question is, will I have any problems in my client-server communication if there are other applications using the same port? I suppose my server will pick up that communication as well? I would like to avoid any possible conflicts with other app's.
Yes you will have problems, if there is an application which is listening to port 80, then you can not use that port.
Notice, Browsers use port 80 as target ports, they don't listen to 80. So, don't count them when you want use that port.
If I understand your question correctly, you appear to be concerned about the ports on the client-side, not the server side. Your application is free to connect to a server which is listening on port 80 and it will not interfere with any other client applications running on the same machine. If it did interfere, things like multiple browsers / tabs would not be possible.
There are some excellent answers on this question which explain in more detail how ports work.
There can only be problems if there are other servers listening on port 80 on the server machine. In this case your application would not be able to bind to port 80. The app will not interfere with web browsers, because they use a random port on the client side.
If the network uses application-layer firewalls, they can block non-HTTP data over port 80. So if your application uses port 80 simply 'because it is not protected by most firewalls', be prepared for such more strict firewall settings, which do not allow your client/server communication.
I have both a client and server application using UDP port 25565.
In order to run these on the same machine, because only one application may bind itself to port 25565, does this mean that it is necessary for me to use two separate ports for transmitting data between the applications?
What I have in mind is the following -
Client -> 25565 -> Server
Client <- 25566 <- Server
Is this the only solution or is there another way of handling this?
Your server application open a port and wait for client to connect.
Client need to know this port in advance so it can establish a connection to the desired service.
Client can use any available ports to initiate this connection (better to use ports > 1000).
The server sees in the incomming packet wich port the client is using, so it will send anwser to it. No need to specify it in your design.
After handshake the TCP/IP connection is then identified by these 4 values : server IP, server port, client IP, client port.
No other connection could have the same four values.
To answer your question. A TCP/IP connection is bi-directional, once established, the server can send data to the client and the other way around.
I would draw the scheme like this :
SERVER port 25565 <-> CLIENT port 25566 (or any other port)
Well, no. Only the server needs to listen on the port 25565 - the client will just connect to that port. There is no reason to specify which client the port should 'use' to connect to that port. Also, once the server has accepted the connection, the port can listen for other requests.
The whole point of separate UDP ports is to eliminate conflicts among applications listening to incoming packets. Changing one of these ports is probably the best solution.
However, if you really want both programs to listen on the same port you will need to use virtual network interfaces such as TUN/TAP (there is a Windows port). Then both applications will bind to the port with tha same number but on the different network interfaces.