I'm trying to replace a inetd/xinetd service by a standalone one.
What is the simplest I can do this? Is there some standard code to get started?
How does inetd know which process to send incoming data to
It spawns it (typically using fork() followed by exec*()), so it has the process-id.
Is there some standard code to get started?
What about xinetd's sources?
Related
I have a question regarding on how to design the following system:
My system is built of several clients listening to an environment. When a audio threshold is breached they send their information to a server, that has children listening on each connection. The server needs information from all the clients to make the necessary calculations.
Currently the server is working in UNIX and has forked out connections. They are working independently.
What I want to do is to tell the parent (in the server) that information has been sent and it's now time to process it. How should I do it?
I'm thinking of possible different ways to do it:
Using signal()in Unix to somehow tell the parent that something has happened
Convert to Threads and use some wait and notify functions
The signaling is preferable but I cannot figure out how to do it efficiently. Because the following can happen in my system:
If all the clients successfully sent information to their children of the server, how can I tell the parent that I'm ready in a efficient way? Don't know/I'm uncertain of how it will process them.
The server may not receive information from all clients. So the parent must wait for awhile for all the children but not too long. So I'm guessing some sort of timer?
Doen't use fork, and don't use signals. Use a thread pool.
What about a Unix Domain Socket for an inter-processes communication between children and father?
http://en.wikipedia.org/wiki/Unix_domain_socket
As soon as a child receives data through the TCP connection, the same data will be forwarded to the father process through the Unix Domain Socket and the latter process will be instantly notified
I am writing a simple instant messenger program in C on Linux.
Right now I have a program that binds a socket to a port on the local machine, and listens for text data being sent by another program that connected to my local machine IP and port.
Well, I can have this client send text data to my program, and have it displayed using stdout on my local machine; however, I cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
How would I go about either creating a new process (that listens and displays the text sent to it by the client machine, then takes that text and sends it to the other program's stdout, while the other program takes care of stdin being sent to the client machine) or create 2 programs that do the separate jobs (sending, receiving, and displaying), and sends the appropriate data to one another?
Sorry if that is weirdly worded, and I will clarify if need be. I looked into exec, execve, fork, etc. but am confused as to whether this is the appropriate path to look in to, or if there is a simpler way that I am missing.
Any help would be greatly appreciated, Thank you.
EDIT: In retrospect, I figured that this would be much easier accomplished with 2 separate programs. One, the IM server, and the others, the IM clients.
The IM Clients would connect to the IM server program, and send whatever text they wanted to the IM server. Then, the IM server would just record the data sent to it in a buffer/file with the names/ip's of the clients appended to the text sent to it by each client, and send that text (in format of name:text) to each client that is connected.
This would remove the need for complicated inter-process/program communication for stdin and stdout, and instead, use a simple client/server way of communicating, with the client programs displaying text sent to it from server via stdout, and using stdin to send whatever text to the server.
With this said, I am still interested in someone answering my original question: for science. Thank you all for reading, and hopefully someone will benefit from my mental brainstorming, or whatever answers come from the community.
however, i cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
The same socket that was returned from a listening-socket by accept() can be used for both sending and receiving data. So your socket is never "busy" just because you're reading from it ... you can write back on the same socket.
If you need to both read and write concurrently, then share the socket returned from accept() across two different threads. Since two different buffers are being used by the networking stack for sending and receiving on the socket, a dedicated thread for reading and another dedicated thread for writing to the socket will be thread-safe without the use of mutexes.
I would go with fork() - create a child process and now you have two different processes that can do two different things on two different sockets- one can receive and the other can send. I have no personal experience with coding a client/server like this yet, but that would be my first stab at solving your issue...
As #bdonlan mentioned in a comment, you definitely need a multiplexing call like select or preferably poll (or related syscalls like pselect, ppoll ...). These multiplexing calls are the primitive to wait on several channels at once (with pselect and ppoll able to atomically wait for both I/O events and signals). Read also the select tutorial man page. Of course, you can wait for several file descriptors, and you can wait for both reading & writing abilities (even on the same socket, if needed), in the same select or poll syscall.
All event-based loops and frameworks are using these multiplexing calls (like poll or select). You could also use libevent, or even (particularly when coding a graphical user interface application) some GUI toolkit like Gtk or Qt, which are all based around a central event loop.
I don't think that having a multi-process or multi-threaded application is useful in your case. You just need some event loop.
You might also ask to get a SIGIO signal when data arrives on your socket using fcntl with F_SETOWN, but this is not very useful for you. Then you often want to have your socket non-blocking.
I'm learning about TCP/IP and am trying to use it to execute different commands on my server.
I thought i'd start small and build up. I've got a current example running which has a server and client connect, and then the server sends the current time to the client.
Now i want to make it such that the server can handle multiple clients.
How can I do this? I think i could use fork, but is there a way to do it without having multiple processes to worry about?
Are there any good primers on this sort of thing, or could you provide some instructions on how to modify my existing code?
Thanks,
glibc Manual has a nice example. The missing code bits can be found earlier in the chapter. The nice thing about the example is that you do not need multiple threads
I would recommend the use of threads:
One server thread has the sole purpose of listening at the server socket for incoming connections. Once a connection is received, it is passed off to a worker thread, while the server keeps listening.
One or more worker threads. These threads will do the majority of the work. You can choose to use one thread per socket, or you can use the select function to allow one thread to handle multiple sockets.
I don't know any primers off the top of my head, sorry.
Take a look at Erik's answer on this other question. You don't really need to do multithreading.
I have a TCP Svr process written in C and running on CentOS 5.5. It acts as a TCP Server for external clients and also does some IPC communication with other processes in the system using Unix Domain Sockets it has establised. It's not a multi threaded process. It does one task at a time. There's an epoll_wait() I use to listen for requests on either the TCP socket or any of the IPC sockets it has established with internal processes. When the epoll_wait() function breaks,I process the request for whoever it is and then go back into epoll_wait()
I have a TCP Client that connects to this Process from outside (not IPC). It connects sucessfully, sends a request msg, gets a response back. I've put this in an infinite loop
just to test out its robustness etc.
After a while, the TCP Server stops responding to requests coming from TCP Client. The TCP client connects successfully, sends a request message, but it doesnt get any response msg back from the TCP server.
So I reckon the TCP server is stuck somewhere else, trying to do something and has not returned to the epoll_wait() to process
other requests coming in. I've tried to figure it out using logs, but thats not helping me understand where exactly the process is stuck.
So I wanted to use any debugger that can give me some information (function name would be great), as to what the process is doing. Putting breakpoints, is overwhelming cause the TCP Server process has tons of files and functions....
I'm trying to use DDD on CentOS 5.5, to figureout whats going on. I attach to the process successfully. Then I click on "Step" or "Stepi" or "Next" button....
but nothing happens....
btw when I use Eclipse for debugging, and attach to this process (or any process), I always get "__kernel_vsyscall()"....Does this mean, the program breaks by default at
whatever its doing? If thats the case, how do I come out of the __kernel_vsyscall() call, to continue within my program? If I press f8, it comes out, but then I dont know where it was, since I loose the stack trace....Like I said earlier. Since I cant figure where it was, I dont know where to put breakpoint....
In summary, I want to figureout where my process is stuck or what its doing and try to debug from that point on....
How do I go about this?
Thanks
Amit
1) Attaching to a C process can often cause problems in itself, is there any way for you to start the process in the debugger?
2) Using the step functions of DDD need to be done after you've set a breakpoint and the program is stopped on a command. From reading your question, I'm not sure you've done that. You may not want to set many breakpoints, but is setting one or two in critical sections of code possible?
In summary, What I wanted to accomplish was to be able to find where my program is stuck, when it hangs. I figured it out - It was so simple. Create a configuration in Eclipse ...."Debug Configurations->C/C++ attach to application"...
Let the process run normally from shell (preferably with a terminal attached). When it hangs, open eclipse, click on the debug icon and run the configured process. It'll ask you to attach to a process. Look for your process name and attach to it.
Now, just look at the entire stack trace....you'll see some of your own function calls mixed with kernel function calls. That tells you where the program is stuck.
I am using C language and Linux as my programming platform.
I am developing a user-space application that runs in a background, like a daemon. And my problem is, I want another user-space application to communicate with this daemon.
I know that I have to use Interprocess Communication method but I don't know what is the correct implementation.
But using IPC in my communication implementation is my other option. Actually I just want to change the attribute of my daemon by using another application. Please see below a senario:
My daemon runs in a background.
Then some application will control the properties of a daemon, like sleeping delay time.
My first option is by accessing a file with the values of the properties. So that my deamon will poll that values. While the other application will change that values.
I am not sure the efficiency of my options. Please advice.
THanks.
Updating the config file and sending a signal to cause re-read is a standard practise, cheap and easy.
You're looking for D-Bus. Store the initial values in a file, then listen over D-Bus for requests to change it.
Unix domain sockets are a simple IPC method.
If I were you, I'd forego IPC completely and instead have the daemon monitor a config file for changes. IPC is only really needed if you're going to be sending thousands of messages per second and the overhead would get intolerable.
inotify is an option for file monitoring.
I'd make the daemon listen on a pipe/fifo if it's simple enough that you only need to read a couple of bytes fed in from another program. Otherwise a local domain socket is nice to run a simple protocol over.