HTTP Ports in .NET Remoting - remoting

Is there a limit to the number of HTTP ports in a machine. I have a windows application that uses .NET Remoting. Each instance of the application, exposes a Remote object on load, through a HTTP Channel with port 0 (so that port can be decided dynamically). In a Multi user environment, will there be a limit to the number of HTTP Ports.
Thanks in Advance!

Yes there will be a limit to the number of ports available which is 65535 minus the number of ports already in use for existing services (for example, SMTP [25], HTTPS [443], SQL Server [1433], etc).
So on a typical Windows server, a finger in the air calculation would be 65535 - 1024 (the well know service ports <= 1024 which are considered out of bounds) - another 10-20 or so possible other application (SQL Server, MySQL, Oracle, etc). This would leave around 64490 post available.
However will you really be running 64000 of instances of your server?

Related

Connecting one server from single machine multiple times vs connecting one server from multiple machines

I am setting up load test for SaaS platform.
I want to benchmark 20 clients connect to SaaS Platform and push some data.
Each client can send maximum of 2 MB and average of 200 Bytes data to SaaS endpoint.
Which one testing is better setting up 20 Clients on single machine or setting up 20 Clients on 5 different machines?
I want to know from TCP stack point of view?
Now when we run 20 clients in a single machine, it will create connection to same destination address and destination port but 20 different Source Ports.
However in background will it use same TCP connection to push data of 20 clients?
From "TCP stack" point of view one "client" == one "connection". If the server doesn't have any background logic to check source IP address in order to restrict requests rate - you can go for a single machine.
See Connection establishment for more information.
In general you need to mimic real life usage of the SaaS platform by end users (or upstream/downstream systems) as close as possible so carefully choose a load testing tool which can produce the same network footprint in terms of creating connection, re-using it and keeping it alive

TCP socket 'deleted' every 6 minutes on Windows Server 2012 R2

We have to migrate a System with our software from a Windows Server 2003 to a Windows Server 2012 R2. At this project we just changed the server hardware (to a HP ProLiant Server), the OS and the ISDN card with the CAPI driver. On this server there is a C++ application which filters a 30 byte character string out of the ISDN D-Channel and send it over a TCP socket (localhost, port 30000) to a JAVA application. The message comes every 30 seconds and has always the same format.
The problem is: Every 6 minutes the TCP socket is getting deleted/cleared/doesn't work. Both applications log the broken communication in their log files, build and open the socket again and the game goes on without any problems for another 6 minutes.
At the old system, this software works for years without any problems on Windows Server 2003 on 9 sites.
What we've already done without any positive effect:
deactivate the firewall completely
change the port to different ones (30001, 30500, 16000, 997)
use the own IP (10.16.58.30) instead on localhost
put several timeouts to the TCP Parameters at the registry (e.g. KeepAliveTime)
update JAVA to the last version
install all recommended updates for Windows Server 2012 R2
strip both applications down to just the socket to ensure that the software itself hasn’t any problem
using a standard message ('1234567891234567890') instead of the incoming ISDN message to exclude malfunction from strange input data
checking the message length to exclude a length of 0
checking all buffers on both sides to exclude buffer overflow
checking if any other software on the server is using 'our' port
The problem doesn't appear, if we're sending the messages from outside manual or in different message cycles with a bash script to the server port of the JAVA app.
We are now thinking that this can only be some kind of checking mechanism of the operating system that forces our socket to stop communication. Any suggestions, what that could be?

Is there a Windows socket API call / option to "block" a range of ports à la SO_EXCLUSIVEADDRUSE

In this (rather old) article, the author states:
"Port Blocking
Port blocking allows an application to prevent other applications from performing specific binds to the ports within a specified range. When blocking a port range, the application must choose a contiguous range of port numbers that are between the value of the MaxUserPort setting (5000 by default) + 1 and either 49151 (for Windows XP and Windows Server 2003 with no service packs installed) or 65535 (for Windows Server 2003 Service Pack 1). There should be no existing bindings to the ports within the range of blocked ports. Windows Sockets returns the last port number in the blocked range as the handle. When unblocking (removing the block), Windows Sockets unblocks the range that has the same left edge as the unblock request."
The implication I get from reading this is that there is some api an application can use to set/unset this, but I have drawn complete blanks trying to search documentation for any such thing, nor do I recall ever seeing such functionality in my socket programming days.
Is there such a capability in Windows, and if so, pointers to documentation of it will be heartily appreciated!
There is no such call in the winsock API itself, but I believe there is in the LSP feature. Another (easy but dirty <3) way is to just bind() to all the ports you want blocked.
You can set the range of ports which will be used for dynamic clients (binding to any available socket) on the system by the MaxUserPort registry value (applicable from Vista onwards). The dynamic port range can be set for tcp and udp sockets. More details in the following links :
MaxUserPort
KB929851
So you can set the range (to allow), as per your needs

TCP: Address already in use exception - possible causes for client port? NO PORT EXHAUSTION

stupid problem. I get those from a client connecting to a server. Sadly, the setup is complicated making debugging complex - and we run out of options.
The environment:
*Client/Server system, both running on the same machine. The client is actually a service doing some database manipulation at specific times.
* The cnonection comes from C# going through OleDb to an EasySoft JDBC driver to a custom written JDBC server that then hosts logic in C++. Yeah, compelx - but the third party supplier decided to expose the extension mechanisms for their server through a JDBC interface. Not a lot can be done here ;)
The Symptom:
At (ir)regular intervals we get a "Address already in use: connect" told from the JDBC driver. They seem to come from one particular service we run.
Now, I did read all the stuff about port exhaustion. This is why we have a little tool running now that counts ports and their states every minute. Last time this happened, we had an astonishing 370 ports in use, with the count rising to about 900 AFTER the error. We aleady patched the registry (it is a windows machine) to allow more than the 5000 client ports standard, but even then, we are far far from that limit to start with.
Which is why I am asking here. Ayneone an ide what ELSE could cause this?
It is a Windows 2003 Server machine, 64 bit. The only other thing I can see that may cause it (but this functionality is supposedly disabled) is Symantec Endpoint Protection that is installed on the server - and being capable of actinc as a firewall, it could possibly intercept network traffic. I dont want to open a can of worms by pointing to Symantec prematurely (if pointing to Symantec can ever be seen as such). So, anyone an idea what else may be the cause?
Thanks
"Address already in use", aka WSAEADDRINUSE (10048), means that when the client socket prepared to connect to the server socket, it first tried to bind itself to a specific local IP/Port pair that was already in use by another socket, either an active one or one that has been closed but is still in the FD_WAIT state. This has nothing to do with the number of ports that are available.
I'm having the same issue on a Windows 2000 Server with a .Net application connecting to a SQL Server 7.0. There's like 10 servers with the same configuration and only one is showing this error several times a day. With a small test program I'm able to reproduce the error by just establishing a TCP connection on the SQL Server listening port. Running CurrPorts (http://www.nirsoft.net/utils/cports.html) shows there's still plenty of available ports in range 1024-5000.
I'm out of ideas and would like to know if you've found a solution since you've posted your question.
Edit : I finally found the solution : a worm was present on the server (WORM_DOWNAD.A) and exhausted local ports without being noticed.

Maximum number of concurrent TCP/IP connections - Win XP SP3

Does anyone know what is the maximum number of concurrent TCP/IP connections on Windows XP SP3? I am trying to load test a machine and would like to know what is the max number of tcp connections that can be opened by an application (in my case, java application) towards that machine.
Note that often you may be limited by the number of outbound connections supported on the client machine rather than by the number of concurrent connections possible. See this Socket Bind Error for how to tune MAX_USER_PORT to enable more outbound connections from the machine running the tests.
I found some very useful information here:
http://smallvoid.com/article/winnt-tcpip-max-limit.html

Resources