Very Basic Question

I'll take a stab at this as it might help me get it clearer in my head.

*EDIT* Man was what I wrote here first some wrong stuff
listen() is a function you call after you have created your socket and bound to it. The listen() function will simply put your program into a listening state. Apparently this is non-blocking so....
So given pseudo code like this

s = socket(// params here);
bind (s, // other params here);
listen();
accept();

What happens is you create socket s by calling the socket() function. Then you bind that socket to a port with the bind() finction. Next you make a call to listen() which will tell the program to listen on that port but not wait around for a connection to come in. If a client attempts a connection then I think that a connection packet is sent to the server. If during a call to accept() there is a connect packet available then it will accept the connection. Otherwise, connect wil return an error message in the form of an integer.

The listen() is a non-blocking function as I am just now reading and understanding. It also returns an integer that you can check to make sure it is listening.

After that then you have a connection to a client and can use a series of send(), recv() or similar calls to pass information back and forth.

Now I have a question. Since listen() and accept and both non-blocking then you would potentially setup a server program in a while loop similar to this.

s = socket(//8888);
bind(s, 32 // or whatever);
listen();
while(1);
{
accept() any valid incoming connections up until server limit is reached or something else triggers a stop.
}

However, doing things like this would never let the program out of the accept() procedure which would make it blocking no? At this point I can only see handling more logic inside of that while loop
So, how do you handle multiple connections?

Poke me if I'm wrong or misleading or just thickheaded.
Just trying to help us both

Webby

[edited by - websitewill on May 10, 2003 6:02:15 PM]

what you said makes sense, but when I actually implemented that sort of thing in a simple program, it locked up on me after I called accept(). I set up a socket, bound it to a specific port, started listening on that port, and when I call accept it binds my program up something fierce. Do you know why this might be?

Elijah

I''m not sure but maybe if you call accept when there is nothing to accept it might be a problem. accept() might be a blocking function but I don''t think it is. i do know that accept and listen will return error codes if something goes wrong. Both are integers. Try capturing the integer and outputting it. I know it''s locking up on accept but capture it from listen and see what you get. Mayhaps a call to the accept function is an error if indeed the call to listen fails or if there is nothing to accept. I don''t think that''s the case as most of the sample code I have seen is simply written with the accept call following the listen call with no waiting in between. But if it''s locking up at that point then something is certainly wrong.

It''s late right now or I would throw together a simple server client chat prog to test out and share with you. I''ll do that tomorrow just for kicks I think if I can remember.

Cheers,
Webby

I actually have been looking at the previous functions'' return values to make sure there wasn''t an error. socket() returns my socket descriptor which is nonzero I believe, bind returns something other than -1 (the error value), and listen() returns 0 (normal operation) I try to get the integer that accept() returns, but it locks up in the middle of that function, so it doesn''t get that far. Maybe I''m just really dumb.

Thanks,
Elijah

accept() is a blocking system call. It will block untill the tcp three way handshake is complete and then it will return a new descriptor.

So basically it will lock up untill there is a new connection.

Indeed accept(), like a lot of the other socket functions are blocking. This means they block (don''t return) until there is something interesting for your application to look at.

To turn off this blocking you can do something similar to this (Windows):
u_long opt = 1;
ioctlsocket(wins_socket,FIONBIO, &opt);

You can also use the listening socket together with select(). Add the listening socket to the read fd_set, and select() will return with the fd set as soon as you can accept() a connection.

cu,
Prefect

Thanks from the both of us

I had all of that information here in some books but had no way to get to it yesterday. I''m slowly getting all of this stuff committed to memory though. Just give me time

Had I thought about it for more than a minute I probably would have realized what he meant by locking up (hourglass pointer that just sits there and program accepts no other input). For some reason I thought his locking up was something akin to a problem only Ctr-Alt-Del would fix and not just the fact that the server app was sitting there waiting for a connection.

Hope I didn''t mislead too much.
Webby

Thanks everyone for the replies, I think things are a lot more clear now.

Elijah