C
C#3y ago
Asher

✅ Check if port is up

Hey all, I have a process which is running a server on a certain port _port locally, the clients are also connecting on 127.0.0.1, so everything is local. I need a way for the server to tell the clients when to actually connect / if its up, originally I wanted to do a filesystem approach where I create an open.txt file, but that also proved to be bad as the file was always used when clients were originally checking if to connect or not
4 Replies
Asher
AsherOP3y ago
this is what I currently built up, but I was wondering if this is considered "expensive" or is this standard practice
private bool serverIsUp()
{
using (TcpClient tcp = new TcpClient())
{
try
{
tcp.Connect("127.0.0.1", _port);
tcp.Close();
return true;
} catch(Exception)
{
tcp.Close();
return false;
}
}
}
private bool serverIsUp()
{
using (TcpClient tcp = new TcpClient())
{
try
{
tcp.Connect("127.0.0.1", _port);
tcp.Close();
return true;
} catch(Exception)
{
tcp.Close();
return false;
}
}
}
phaseshift
phaseshift3y ago
The file based trick that I thought it for a similar issue is for the server to write the details to blah.txt, then when it's finished, also move the file to open.txt Move is atomic (for the same drive), so there should be no issues with the file being in-use
Pendramon
Pendramon3y ago
If its "expensive" depends on the use case, your available resources, connectivity and load on the server/client. A few ideas to consider: 1. Might be a good idea to add a timeout depending on your use case so that it doesn't take excessively long. 2. This will block further execution until the method completes, if this is not expected behavior and or you are using it on a UI thread consider making the method async and using ConnectAsync method on TcpClient to avoid blocking. 3. You may also send a message and wait for a response to ensure that the server is not only accepting connections but also processing requests. Just throwing this idea out there, not that you should do this but have it in mind that it is an option. For example the server may have performance issues or it may have ran out of resources such as memory or hard disk space. Ultimately as long as you don't have a lot of clients and you aren't doing the checks way too frequently it should be fine. Since you mentioned everything is local I think you may be focused too much on performance on something that may be just barely scratching the surface, I do not know what your use case is though. There are many ways of communicating between processes on a local machine some are more performant than others but its important to note that for some you sacrifice accuracy and reliability for performance. I mean hell, you could even share memory between applications but it doesn't mean that it is a good idea.
Accord
Accord3y ago
Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.

Did you find this page helpful?