fork()'ed or multi threaded socket I/O?

thedevilsjester · 04-20-2005, 05:45 PM

I have some fairly decent socket code written, however I have run into a few problems.

First, using some telnet clients the "accept()" function will not return until they press a key.

Second, while one user is trying to connect (a proccess that can take upto 5 seconds sometimes), the rest of the app is 'on hold' because its a single threaded app.

My code is structured as follows

I have a function that sets up the Listening Port and I have a function that checks the fd(s) using select() and FD_ISSET().

Using google the best answers I could find where using a command fork(), but I couldnt see how that could fix my problem, still being a single thread it would still 'pause' during accept. I also couldnt find any examples of how I could use fork() with my current structure.

The only other option I can see is a multi threaded approch, however I have never written a multi threaded app in C++, and never one using sockets and I dont relish the thought of all of the precautions I will have to take with such an endevor.

Anyone experianced in this field have any ideas?

(Note I do not want to use any 3rd party socket libs, I want to use the basics. I am using Linux and GCC)

rjlee · 04-21-2005, 05:00 PM

Using fork() will make your project multi-processed, so you probably don't want to do that.

I wrote something that uses sockets and select for a single-processed multi-connection server a while ago. I don't remember it having these problems, although I suspect it has some other bugs in the higher-level TELNET stuff. You might want to take a look at it:

http://www.rjlee.dyndns.org/projects/programs/telnet/

Mara · 04-21-2005, 05:07 PM

I'm wondering how is the code written that it stops. I guess you're using blocking functions. Make your socket non-blocking (option O_NONBLOCK, read man fcntl for more info). Then accept will return when there's no new connection. BTW If I remember correctly, you can add the listening socket to select read set and then, if you get that there's something new, use accept (it shouldn't block then).

fork() is not the best idea - your connections probably need to share data and program with fork() will be usually slower than with threads. You use threads nearly the same way as processes (they are ones in fact). Only function names are different.

Probably too much theory... Please post your code - without the unneded details. Only sockect, bind etc, the loop (?) you wait for accept, how your select looks like, where's the code that should be run for the client (function? piece of code? how much data need to be shared?)

aluser · 04-21-2005, 06:59 PM

Assuming you don't want threads or multiple processes, it sounds like you're missing select(). Actually, you can choose between select() and poll(), but it seems like most recent code uses select() (?)

My system has a select_tut man page. There's also google..

The idea is that your loop blocks inside of select(), and is woken up when *any* connection has data ready, or you can accept() on the master socket.

With select(), you basically don't need nonblocking IO. As long as you only read, write, or accept on an fd which select() has declared ready for the operation, you won't block. Actually there is a weird case where you can block caused by broken TCP checksums, so you technically should sed the filedescriptors nonblocking anyway.

As long as you don't operate on port 23, telnet clients should turn off all their extra junk, so you'll just get raw data as you expect.

thedevilsjester · 04-22-2005, 09:25 PM

If you read my post you will see that I mention that I do use select to poll if there are any new connections. Once a connection is in que then I call accept, which (when connecting via localhost) works instantly, however any 'outside' connection can take a few seconds to return.

Is there any linux native way to create a socket with callbacks?

So fork() does make it multiproccessed? Hmm, I need to research this and see if I can just use fork for the 'select&accept' function while the rest remains on the parent proccess...hmm

Here is the current function (stripped for easier reading)

Code:

/*fd's are setup before this line*/ 
char *dataBuffer;
dataBuffer = new char[BUFFERSIZE];
	
if ( select(FD_SETSIZE, &socket_read, NULL, NULL, &tv) > 0) 
{	
	if (FD_ISSET(listening_socket, &socket_read))
	{
		sin_size = sizeof(struct sockaddr_in); 			
		int new_connection = accept(listening_socket, (struct sockaddr *)&their_addr, &sin_size);					
	}	
}

Everything works properly, it only goes to the accept() function if someone is trying to connect (I have verified this countless times), however it will stay on accept() for a period of 1-5 seconds usually. I can even read the ip address of the one trying to connect before the accept() call. This delay wouldnt be a major issue, however since its single threaded the entire app is put on hold for that duration.

If I could have accept() somehow call a function when the connection is made so my app can continue on with its proccessing while accept() is doing its work then that would be perfect...

arun.tayal · 09-24-2008, 12:41 AM

Hi All,

I am also facing the same issue. I am developing a system tray application ,Which will listen to a port for any incoming connection.

Also there is a menu attached with this system tray application, through which user can perform operations.

I have forked a process which will listen to the socket for connection and then perform operations and in the parent thread I am handling the GUI of system tray by calling gtk_main().

What is happening is at the accept() function the code is getting blocked and now even the parent process is not able to function because of this the menu of system tray hangs.

Plz help.

Regards
Arun Tayal