GIDForums  

Go Back   GIDForums > Computer Programming Forums > C++ Forum
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
 
Thread Tools Search this Thread Rate Thread
  #1  
Old 18-Jul-2005, 18:54
ubergeek ubergeek is offline
Regular Member
 
Join Date: Jan 2005
Posts: 775
ubergeek is a jewel in the roughubergeek is a jewel in the roughubergeek is a jewel in the rough

windows sockets confusion


OK, I am using Windows Sockets (version 2.2, on Windows XPSP2 Home) to write what is currently a simple chat program. However, I am a bit confused on a couple of things. First of all, which Windows Sockets functions block? I have a list below; could I trouble someone to correct it?

listen(): does not block, sets socket in a listening state
accept(): blocks until connect() (these first two are especially hazy)
recv(): blocks until something in buffer
send(): ? (does it block until recv() or just put stuff in the buffer and then return?)
shutdown(): ? (I don't really know what it does, either, besides cause errors)
connect(): doesn't block, errors out if connect()ee not listening/accepting (?)

Also, when using listen() to allow multiple connections to queue to be accept()ed (in other words, setting the second parameter of listen() to greater than 1) how do I accept more than the first? I have a feeling it is something to do with loops or threads, but I'm not really sure.

EDIT: I'm using blocking sockets. Do I have to switch to non-blocking sockets to handle multiple clients?
Last edited by ubergeek : 18-Jul-2005 at 20:04.
  #2  
Old 18-Jul-2005, 20:44
nkhambal nkhambal is offline
Regular Member
 
Join Date: Jul 2004
Location: CA USA
Posts: 313
nkhambal is a jewel in the roughnkhambal is a jewel in the rough
listen does not block. It just set the socket in listening mode and sets how many maximum *unhandled* connection can be there for the socket. Unhandled here means the TCP connections which have not gone through Three-way handshake sequence with Server.

Only following function blocks

accpet() until client connects using connect() system call
read()/readfrom() until something is received from client which it sends using send()/sendto() system call.

connect() return immediately once it connects (with return value > 0 ) or fails to connect (with return value as -1) .

send() behaves same as connect() and returns immediately with success or failure.

the one way to handle multiple connections from client is by using select().

When a new client connects to the server, the accept() call on Server returns with a new socket descriptor for the new client. This new socket descriptor can then be used with select() to send/receive data between client and server. The process repeates for each new client i.e. you need to run it in infinite loop. accpet() will keep on blocking untill new connection is received.

Basically, what select() does is, it keeps scanning a descriptor set (fdset) for the readiness of the sockets added to the set. The new socket descriptor returned by accept() during each return is added to the "fdset" and given to select() for scanning or polling.

Following is a rough pseudocode

Code:
create a server socket start listening on server socket add the server socket in socket set /*fdsets*/ start infinite loop scan fdset using select to check if any socket is ready for send/recv. if any socket is ready /*select returns with > 0 value*/ then check if the ready socket is our server socket. if it is, accept new connections /*accpet() blocks*/ till new connection received and then add the new socket descriptor to our fdset. else just perform send/recv on any socket which is ready for it. go back to infinite loop.

select() system call is also blocking till any socket is ready in the set or timeout occurs. Making timeout as 0 will cause select() to timeout immediately if none of the socket is found ready after scanning the set.

Another way to handle the multiple incoming client connections is to launch a new thread or process with every return of accept() system call. Each connection will thus be handled in the new thread. This is a very complicated approach which adds lots of complexities and overhead.

For a simple chat server like application I would recommend select() based approach.

Check Beej's guide for a further information on select() and how to use it practically in your code.

Beej's Guide to Network Programming

Thanks,
 
 

Recent GIDBlogMore photos on Flickr by crystalattice

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Command & Conquer 95 under XP dexter Computer Software Forum - Games 41 29-Jun-2008 12:45
Can't update after Windows Update KB835732 crassbones Computer Software Forum - Windows 3 22-Oct-2005 01:57
CDialog::Onsize problem in Windows 2000 Professional Environment vikravel MS Visual C++ / MFC Forum 0 31-Jan-2005 06:59
Trouble with Windows XP vsseym Computer Software Forum - Windows 29 12-Aug-2004 03:56

Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The

All times are GMT -6. The time now is 01:04.


vBulletin, Copyright © 2000 - 2008, Jelsoft Enterprises Ltd.