Is there an easy way to determine if a file on a remote system exists without a 20-25 second hang if it doesn't?
Functions like...
PathFileExists();
GetFileAttributes();
...don't allow you to set a timeout duration, so when the file doesn't exist you end up waiting for a long time. I think it might be possible to put one of these calls into a thread and set the thread to expire after 1 second (or whatever), but I'd prefer to use a lightweight native Windows function or boost function rather than an inelegant threading solution.
It's a bit hard to prove a negative, but I will argue that no such method exists.
The normal Windows asynchronous I/O method uses the OVERLAPPED structure, and in its documentation it references the ReadFile and WriteFile methods. From the other side, no variant of GetFileAttributes mentions OVERLAPPED or asynchronous I/O. Hence, it seems safe to assume it is always synchronous.
AFAIK no, generally there’s no easy way.
If your server is configured to responds to pings, you can use IcmpSendEcho API to ping the server before accessing it’s shared files, the API’s quite simple and it accepts the timeout.
If your server doesn’t respond to pings (by default modern versions of Windows don’t), you can write a function that tries to connect to TCP port 135 or 445, if connected closes the connection and returns success, if failed returns error. This will allow you to implement shorter timeout than the default.
In both methods, you’ll need to resolve the network drive path into the name of the server, see e.g. GetVolumePathName API.
Related
I'm trying to create a method that determines access to the ntp server. I made a simple method, but if there is no connection, then it waits a long time for an answer - 5 seconds. I check 5 servers like this, for example - time.nist.gov. We have to wait a very long time.
Question: is there an easy way to check to avoid waiting so long, about 1-2 seconds?
bool is_connection(char* url)
{
// time.nist.gov
return gethostbyname(url) != NULL;
}
First, you should do all these checks in separated threads and join them to get the whole results in a single request.
Second, NTP uses UDP, so you can't check if the port (123 for NTP) is open or not, since UDP isn't a connected protocol - i.e. you don't have delivery results unless the server sends back another datagram to acknowledge your datagram. With TCP, you can "ping" a port to check if it's open, but not in UDP. You'll need to dive into RFC 1305 in order to be able to check that.
Resolving the name won't help you to check if it's a valid and working NTP server.
Anyway, your problem can be easily solved, but the solution is most likely dependent of your operating system (type, version, ...), your compiler (type, version, C++ standard used, ...), and the allowed C++ frameworks for your case (open bar, restricted, portable or not, ...).
I highly doubt that an EFFICIENT solution in pure portable C++ exists, in particular if you're stuck with old C++ standards. An efficient solution is more likely totally platform-dependent.
You should precise your working environment in order to get a more precise solution.
I have a client/server program written in C++. I want to check the client response (an attribute of a C++ object) through a command send by the server, with a timeout if no response.
I am waiting for an expected value during some seconds. If the expected value is not observed, I need to return with a timeout. I was thinking about a thread and a poll to check the expected value in an specific time interval.
I wonder if C++11/14 features - std::promise, std::future, std::condition_variable or something else - can do it more easily for this case. The inconvenient i see about it is that i have to notice each changing value with a notify.
Well, i need some advice.
None of the C++ language features you mentioned can help in your scenario, because they are intended for interaction within a single running program - which may be multi-threaded, but not separated into two completely independent processes.
However, the networking library you are using (on the server side) might possibly have convenience facilities for doing this.
I realize this is a general and somewhat vague answer, but your question was also not very specific.
How to wait for a value with timeout
Within a process, one would typically use a condition variable.
I want to check the client response ... through a command send by the server
There is no standard way to communicate between processes in C++ (unless you count interaction with filesystem). As such, there is also no standard way to enforce a timeout on such communication.
Before you can know how to implement the timeout, you must figure out how you are going to communicate between the client and the server. That choice will be affected by what system you are targeting, so you should first figure that out.
If you are on a Linux environment you can try rpcgen and play with .x flies but you’ll have to study it a bit. Not sure for Windows env. Also you can use Dbus which is more intuitive.
[edit] Dbus or probably libdbus for you is an IPC cross platform toolkit or library that can fit your need. RPCGEN is an old tool that does the same thing but more complicated. I don’t have a snippet, I apologize but you can search for “qt dbus example”.
About the first requirement, server waits for a response with a timeout.
Have you tried select() or poll(). They can help us to monitor the socket connection between server and client in a period.
Or we can use signal() and alarm(), to check the response after a few seconds.
In Bekerley API, combine setsockopt() with SO_RCVTIMEO, SO_SNDTIMEO can also set the timeout for the request.
I'm not sure about the library you are implementing, but I hope it has any similar functions.
The second requirement, you are waiting for expected value for a duration.
I think condition variable is a good solution for this.
Why not using boost::thread with a timed_join?
boost::thread server_thread(::server_checker_method, arg1, arg2, arg3);
if (server_thread.timed_join(boost::posix_time::milliseconds(1000))) // wait for 1s
{
// Expected value found in the server in less than 1s
}
else
{
// Checking expected value took more than 1s, timeout !!!
}
You can put your checking mechanism in the server_checker_method and return if the expected values are OK. Otherwise, iterate over the loop until the timeout reaches.
Piggybacking on the topic described here (Using libcurl multi interface for consecutive requests for same "easy" handle), my organization has wrapper classes for select and poll to handle input/output from file descriptors. In keeping aligned with our wrapper classes, I would like to get the file descriptor of each easy handle. I'm using the multi interface to work with multiple easy handles in a real time application.
I understand I can use the curl_multi_fd_set to get the FD sets. I could loop through the FD set to get the FD number. However, I won't know the associated easy handle for the FD. Additionally, if an FD is opened above the FD_SET limit, I won't get that FD.
Another option I'm considering is to use the curl_easy_getinfo and use the ACTIVESOCKET or LASTSOCKET options. My libcurl is old, so I couldn't use the ACTIVESOCKET for a test. However, a little test I performed using the curl_multi_perform, followed by a curl_easy_getinfo(LASTSOCKET) gave me a result of -1 -- meaning no file descriptor. Easy handle requests were performed on websites such as google.com. I'll try to update my libcurl to a newer version to see if I get a different result with the ACTIVESOCKET.
Is there another way to get the file descriptor from the easy handle?
I would propose you switch over and use the multi_socket API instead, with curl_multi_socket_action being the primary driver.
This API calls you to tell you about each and every socket to wait for, and then you wait for that/those and tell libcurl when something happened on that socket. It allows you to incorporate libcurl into your own IO loop/socket wrapper systems pretty easily.
For every single tutorials and examples I have seen on the internet for Linux/Unix socket tutorials, the server side code always involves an infinite loop that checks for client connection every single time.
Example:
http://www.thegeekstuff.com/2011/12/c-socket-programming/
http://tldp.org/LDP/LG/issue74/tougher.html#3.2
Is there a more efficient way to structure the server side code so that it does not involve an infinite loop, or code the infinite loop in a way that it will take up less system resource?
the infinite loop in those examples is already efficient. the call to accept() is a blocking call: the function does not return until there is a client connecting to the server. code execution for the thread which called the accept() function is halted, and does not take any processing power.
think of accept() as a call to join() or like a wait on a mutex/lock/semaphore.
of course, there are many other ways to handle incoming connection, but those other ways deal with the blocking nature of accept(). this function is difficult to cancel, so there exists non-blocking alternatives which will allow the server to perform other actions while waiting for an incoming connection. one such alternative is using select(). other alternatives are less portable as they involve low-level operating system calls to signal the connection through a callback function, an event or any other asynchronous mechanism handled by the operating system...
For C++ you could look into boost.asio. You could also look into e.g. asynchronous I/O functions. There is also SIGIO.
Of course, even when using these asynchronous methods, your main program still needs to sit in a loop, or the program will exit.
The infinite loop is there to maintain the server's running state, so when a client connection is accepted, the server won't quit immediately afterwards, instead it'll go back to listening for another client connection.
The listen() call is a blocking one - that is to say, it waits until it receives data. It does this is an extremely efficient way, using zero system resources (until a connection is made, of course) by making use of the operating systems network drivers that trigger an event (or hardware interrupt) that wakes the listening thread up.
Here's a good overview of what techniques are available - The C10K problem.
When you are implementing a server that listens for possibly infinite connections, there is imo no way around some sort of infinite loops. Usually this is not a problem at all, because when your socket is not marked as non-blocking, the call to accept() will block until a new connection arrives. Due to this blocking, no system resources are wasted.
Other libraries that provide like an event-based system are ultimately implemented in the way described above.
In addition to what has already been posted, it's fairly easy to see what is going on with a debugger. You will be able to single-step through until you execute the accept() line, upon which the 'sigle-step' highlight will disappear and the app will run on - the next line is not reached. If you put a breadkpoint on the next line, it will not fire until a client connects.
We need to follow the best practice on writing client -server programing. The best guide I can recommend you at this time is The C10K Problem . There are specific stuff we need to follow in this case. We can go for using select or poll or epoll. Each have there own advantages and disadvantages.
If you are running you code using latest kernel version, then I would recommend to go for epoll. Click to see sample program to understand epoll.
If you are using select, poll, epoll then you will be blocked until you get an event / trigger so that your server will not run in to infinite loop by consuming your system time.
On my personal experience, I feel epoll is the best way to go further as I observed the threshold of my server machine on having 80k ACTIVE connection was very less on comparing it will select and poll. The load average of my server machine was just 3.2 on having 80k active connection :)
On testing with poll, I find my server load average went up to 7.8 on reaching 30k active client connection :(.
I have two applications running on my machine. One is supposed to hand in the work and other is supposed to do the work. How can I make sure that the first application/process is in wait state. I can verify via the resources its consuming, but that does not guarantee so. What tools should I use?
Your 2 applications shoud communicate. There are a lot of ways to do that:
Send messages through sockets. This way the 2 processes can run on different machines if you use normal network sockets instead of local ones.
If you are using C you can use semaphores with semget/semop/semctl. There should be interfaces for that in other languages.
Named pipes block until there is both a read and a write operation in progress. You can use that for synchronisation.
Signals are also good for this. In C it is called sendmsg/recvmsg.
DBUS can also be used and has bindings for variuos languages.
Update: If you can't modify the processing application then it is harder. You have to rely on some signs that indicate the progress. (I am assuming you processing application reads a file, does some processing then writes the result to an output file.) Do you know the final size the result should be? If so you need to check the size repeatedly (or whenever it changes).
If you don't know the size but you know how the processing works you may be able to use that. For example the processing is done when the output file is closed. You can use strace to see all the system calls including the close. You can replace the close() function with the LD_PRELOAD environment variable (on windows you have to replace dlls). This way you can sort of modify the processing program without actually recompiling or even having access to its source.
you can use named pipes - the first app will read from it but it will be blank and hence it will keep waiting (blocked). The second app will write into it when it wants the first one to continue.
Nothing can guarantee that your application is in waiting state. You have to pass it some work and get back a response. It might be transactions or not - application can confirm that it got the message to process before it starts to process it or after it was processed (successfully or not). If it does not wait, passing a piece of work should fail. Whether when trying to write to a TCP/IP socket or other means, or if timeout occurs. This depends on implementation, what kind of transport you are using and other requirements.
There is actually a way of figuring out if the process (thread) is in blocking state and waiting for data on a socket (or other source), but that means that client should be on the same computer and have access privileges required to do that, but that makes no sense other than debugging, which you can do using any debugger anyway.
Overall, the idea of making sure that application is waiting for data before trying to pass it that data smells bad. Not to mention the racing condition - what if you checked and it was OK, and when you actually tried to send the data, you found out that application is not waiting at that time (even if that is microseconds).