(I am using Cocoa API)

there is one stand-alone server and the all the game clients connect to it... there is an unknown amount of clients.

This is the agorithim that I started:

if multiple clients can't connect to the same socket... would I just create a new socket after the one before it was connected to? but what about the port? can I bind multiple sockets to the same port?

please share your agorithim to this problem, or even source code...

thanks!
-Z

also to clarify this alittle bit:

i am using TCP/IP because i wont be sending a whole lot of information, and I dont expect to loose any of it.

For a server, this is what you usually do


I hope my bad pseudo-code isn't too unreadable

(cough BEEJ cough)

Double-check the way accept handles connections -- you have the (typically blocking) wait to listen, and when a connection is established with another machine, the method returns a valid file descripter (socket int). This returned socket is valid for both reading and writing; you want that returned descripter for communication to work! There are two ways from getting a connection to work: you can fork the process with the child process turning itself into a responsive server, or you can throw the socket onto the fdset, and feed all your connected sockets into select().
Select() is great fun. You hand the method a set of file descripters, and it trims its argued sets down to the sockets ready for reading, writing, accepting, or disconnecting. Because of the way UNIX handles files, you can use select() with files, sockets, and the standard pipes -- proper use of select() can give you non-blocking console input in a loop by adding fd 0 (stdin).

If you go the forked route, don't forget to clean up the children. If you use select(), you'll want your clients in a list or a bit-masked array.

-"Sta7ic" Matt

Quote:Originally posted by Steven

Code:

while(running){
create socket
bind it
accept connection
fork a process ---->
repeat
}

->
forked process
while(active){
read game data
process
write game data
synchronize
repeat
}
after end of game
cleanup
end

but when you "accept" a connection, isnt that only one client? or is that just any thing that connects to you?

I guess I dont understand how the connect works... I am imagining the server as an electrical socket, and the client as a plug... so only one client or plug can go in each socket and it stays until the app terminates (or you close())...

Yes, that's only one client, but as soon as it connects the port is free to accept another connection. How do you think HTTP servers accept thousands of connections at once, all on port 80?

For lack of a better metaphor, think of ports as instant messenging handles or ICQ UINs. You need it to initiate a conversation, but after you start it you don't need to know what it is to continue. Additionally, other people can start conversations too without interrupting your conversation in progress.

Multiplexing sockets using select is generally much more scalable.

It doesn't take many connections before forking becomes a resource problem.

Wade

Never used select, so don't listen to me

what does forking actually do?

Quote:Originally posted by Steven
Yes, that's only one client, but as soon as it connects the port is free to accept another connection.

so you only need one socket?

Forking essentially creates a copy of the current process. It's much more complicated than that, but that's a simple description.

As someone noted, you do in fact, only create one listening socket. When you use accept, it creates a copy of the listening socket, which then frees up the listening socket to accept more connections.

For starters, read "man 3 accept" and pick up some socket programming books.

Wade

Okay: If you're using OS X, you're using UNIX. UNIX handles everything as a file, including directories, devices (look in /dev/ ), terminals, and sockets. If you can use fprintf and freadf, or iostream::read() and iostream::write(), for all intents and purposes, you can use send() and recv(). When you open or connect a socket, UNIX treats it as a specialized file. Any and all UNIX C methods that work on files will work with

Servers have two *sets* of sockets. The first set is the Listening Set, the second is the Connected Set. You only need one listening socket to get any number of connections.

Using fork() copies the calling process lock, stock, and barrel at the time it's called. Try the man fork page for more details.

-"Sta7ic" Matt

alright thanks Matt