I am trying to write an application in c++ using winsock.
I need to handle a case where default port used by the app is not open to use then what is fallback mechanism?
Server or client?
In the server, if the requested port is already taken, you log an error and stop. This is why ports are often stored in configuration.
For the client, if you cannot connect to the specified port, you log an error too. Its not much different from not being able to connect to any other network resource, like a URL in your browser.
That completely depends on you.
There is a mechanism called port knocking: The application just tries a range of ports until it finds one it can bind to. Obviously server AND client have to do this to find each other if the default port did not work out.
You could also just display an error message and let the user decide on how to deal with this.
Or you specify a fallback port in a config file...
Just to give you an idea.
Related
I am working on a project need to send periodic alive message to https server.
Because of security issue, we need to use minimal number of ports (blocking unused ports as many as we can).
I am using c++ libcurl easy interface to send https request in linux.
I have tried to use the same curl handler object (CURL object) and set CURLOPT_LOCALPORT to a port number. The first request is ok. But in the second, libcurl verbose mode said address already in use.
However, when I comment out the port set through CURLOPT_LOCALPORT, it works on second connection also, and by setting VERBOSE to 1, I can see "Re-using existing connection" print out, which is missing in version setting up local port.
And I check with linux netstat, find out that it is using the same port.
I cannot figure out why setting up local port will make it failed.
And also, I have tried to close the connection using curl_easy_cleanup, but due to tcp time_wait state, we cannot reuse the port in a while, that's not what I want.
Could anyone provide a solution or suggestion to us? Thanks a lot.
Edit
My reason using one port is not to keep opening and closing connection too much.
Because of the security issue ...
There is no security issue. You need to get over this phobia about using multiple local outbound ports. There is zero security benefit in using fewer, or in constraining them in any way.
I have a solution that acts as client service and does some background work. This application requires some settings (that are read from an xml file) to be done at installation time and which are periodically revised. For convenience (as this service is installed on multiple machines) I wanted to control these settings remotely from a central server application. This works fine if the server and client are inside the LAN but I would like to control these settings even if the client is outside the network or the server is behind a firewall. What could be the solutions to do this?
Clearly, the solution depends on exactly what you want to achieve. But if I understand it right, the reason you have "problems" with a firewall is that you simply access the file that contains the XML over the network using standard network file access. Which is typically (for good reason) blocked by the firewall.
So, the solution then would be to use a standard protocol and a "non-standard service". For example, if the machine is allowed incomming HTTP requests, you could use HTTP-based post messages to update the XML content, either send the entire file as a file upload, or make up your own remote access protocol. If HTTP is not allowed, then you have to look at what other "holes" there are in the firewall, and do something similar with another of the "holes".
The other, less obscure solution, is of course to simply use a remote-desktop or secure shell connection to remotely access the machine. Of course, again, assuming this sort of connection is allowed.
There is no magical "bypass firewall" solution - you have to work within the rules of the firewall in some way.
I have a system where I want to listen to a socket and wait to client connect and then pass the connection to another application that I'll start as soon as the connection is established.
I do not have control on this other application and can only set the port where it will listen, but I want to have one process for each new client.
This is what I'm trying to do:
I've been searching for a solution, but I thing I don't have the right terminology, but I managed to find on Richard Stevens' "Unix Network Programming" something about the AF_ROUTE family of sockets that may be combined with a SOCK_RAW to route a connection to another IP and port. But there's too little documentation about how to use this flag and seems to require superuser privileges (that I want to avoid).
Maybe there's an easier solution but I'm probably using the wrong terms. Is it clear what I want to do?
I don't think you'll be able to just "pass" the socket like you want to, especially if you can't change and recompile "APP". Sockets include various administrative overhead (resource management, etc) that are linked to the process they are owned by. In addition, if you can't recompile APP, there is no way to make it bypass the steps involved with accepting a connection and simple have an already open connected "handed" to it by your router.
However, have you considered simply using router as a pass-through? Basically, have your "Router" process connect via sockets to the each "APP" process it spawns, and simply echo whatever it recieves from the appropriate client to the appropriate APP, and visa versa for APP to client?
This does add overhead, and you will have to manage a small mapping to keep track of which clients go to which apps, but it might work (assuming the APP or client aren't basing any behavior off of the IP address they are connected to, etc). Assuming you can't recompile APP, there might not be too many other options.
The code for this is relatively simple. Your handler for data recieved from APP just looks up the socket for the appropriate app from your mapping, and then does a non blocking send of this data out on it. Likewise the handler for data recieved from client. Depending on how exactly the clients and app behave, you may have to handle a bit of synchronization (if you recieve from both simultaneously).
I have a third party library that acts as a HTTP server. I pass it an address and port, which it then uses to listen for incoming connections. This library listens in such a way that it doesn't receive exclusive usage of the port and address it's bound to. As a result, I can listen on the same port multiple times.
I need to run multiple instances of this HTTP server in the same process. Each instance has a default port, but if that port isn't available, it should use the next available port. This is where my problem is; I can end up with two HTTP servers listening on the same port.
I cannot change the HTTP server's code and the HTTP server will not alert me if it cannot listen on the port I give it, so I have to be able to check if a port is already in use before starting each HTTP server. I have tried checking if a port is already being listened on by binding my own socket with SO_REUSEADDR set to FALSE and SO_EXCLUSIVEADDRUSE set to TRUE, but the bind and listen calls both succeed when an existing HTTP server is already listening on that port.
How is this HTTP server achieving this effect, and how can I accurately check if a port is being listened on in this manner?
The quick and dirty method would be to try to connect() to the port on localhost. If the connect() call succeeds, then you know the port is currently being listened on (by whomever received the connection). If the connect call fails (in particular with ECONNREFUSED) then you can be pretty sure that nobody is listening on that port.
Of course, there's a race condition here: Nothing is really stopping another program from swooping in and grabbing the port immediately after you ran the above test, but before you get around to binding to the port yourself. So you should take the result of the test as more of a hint than an absolute rule, and (hopefully) have some way of handling it if you later find out that the port is in use after all.
Use a port number of 0. The OS will pick a free port.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx explains how the different options interact.
You haven't given us nearly enough information to tell us exactly what's going on in your use case, but I can work through one arbitrary use case that would look like what you're seeing.
Let's say you're on Win 2003 or later, and your primary NIC is 10.0.0.1, and everything is running under the same user account.
The first instance of your app comes up, and your test code tries to bind 10.0.0.1:12345 with SO_EXCLUSIVEADDREUSE. Of course this works.
You close the socket, then tell the HTTP server to listen to port 12345. It binds 0.0.0.0:12345 with SO_REUSEADDR, which of course works.
Now a second instance of your app comes up, and your test code tries to bind 10.0.0.1:12345 with SO_EXCLUSIVEADDREUSE. According to the chart in the MSDN article, that works.
You close the socket, then tell the HTTP server to listen to port 12345. It binds 0.0.0.0:12345 with SO_REUSEADDR, which works.
If this is the problem, assuming you can't get the HTTP server to bind a specific address, you can solve things by using 0.0.0.0 in your test code. (Of course if it's one of the other hundreds of possible problems, that solution won't work.)
If you don't know what socket options, address, etc. the HTTP server is using, and don't have the source, just run it in the debugger and breakpoint the relevant calls.
The function
listen( ListenSocket, SOMAXCONN )
is detected by avira antivirus as a backdoor model.
How can I write small client/server applications without a listen function?
Is there a way to do it?
If you need to accept connections then no, you can't do that without calling listen.
If you can make your application just a client and have an server running somewhere else then your client can connect to the server and the server can act as a broker for other clients to connect to...
I wouldn't worry about this anyway. If you're running a server that you want to be able to connect to from a machine other than the one it's running on then your documentation will have to explain how to open up firewall ports and whatever so just add details of how to exclude the app from the antivirus applications that it confuses.
Also, your application IS accepting connections from external sources and so the antivirus app is correct to warn the user. You need to educate the user that it's OK for your app to do this because it's doing it for whatever valid reason you have. If you don't want to explain it to the user then, IMHO, you are writing a backdoor ;)
Uninstall Avira Antivirus ;-)
Server, by definition, listens for incoming connections, and clients initiate connections to the server. In TCP/IP networking, the server achieves this by bind()ing and listen() ing to a socket.
Avira is filled with all sorts of false-positives that are trivially easy to work around. Try storing listen into a function pointer and calling it. It'll probably work.
If you're dealing with TCP connections and you know who/where the connection is coming from, and have a third party that can tell you when the connection is going to be attempted, it's valid for both sides to connect to each other at the same time. Doing this can negotiate a connection without either side listening. It's not a good solution and needs a much more complex implementation if a NAT is involved, but it is a possibility if the client and server are on a LAN.