Socket programing

[marlym014]

I need to program both client and server application , I have already manage the connection between them and also transmiting information (a struct) between them, both need to receive a send data so I've got methods to receive and send in both sides, like these:

int SocketClient::sendData(PACKET envio)
{ int iResult;
iResult = send( ConnectSocket, (const char *)&envio, sizeof(envio), 0);

if (iResult == SOCKET_ERROR)
{ printf("send failed with error: %d\n", WSAGetLastError());
closesocket(ConnectSocket);
WSACleanup();
return 1;
}

printf("Bytes: %ld\n", iResult);
printf("Header: %x\n", envio.header);
return 0;
}


int SocketClient::receiveData()
{ PACKET recibo;
int iResult;
iResult = recv(ConnectSocket, (char *)&recibo, sizeof(recibo), 0);
if ( iResult > 0 )
{ printf("Bytes: %d\n", iResult);
printf("Header: %x\n", recibo.header);
}
else
{printf("recv. Error: %d\n", WSAGetLastError());
return 1;
}
return 0;
}


Basically, what I have now is synchonized sequence of commands like this:



int mainClient()
{
send (something);
receive (something);
send(something);
send(something)
}


int mainServer()
{
receive(something);
send (something);
receive(something);
receive(something)
}


And What I want is to detect the when a socket wants to send something so the other one needs to receive, both are console applications and this may be a silly question but I am newbie in c++ and socket programming, any advice?

[zwA4jE8b]

I am new also, but maybe you can use multiple threads, one for sending and one for receiving, that way it is Asynchronous.

[Lv0f92yv]

I know for one chat program I made using java, the client and server side programs both used clientthread/serverthread objects for the actual transmission/receiving of data.

Maybe something like:
A server run on the server side spawns a new thread for every connection. Each thread waits for it's specific socket's input, then forwards it to a synchronized (locked) function in the main server program for handle.

Similarly, each client generates a client thread to handle responses from the server and inputs from the main client program to then be forwarded to the server.

This is kind of a long winded response, but it might clarify some things... If desired, I can send OP the java version of my chat program.

[ultifinitus]

A server run on the server side spawns a new thread for every connection.

NOOOO000ooooooooo!!!! I wasted sooo much time on blocking sockets with hundreds of threads. In the beginning it's fine, but it's not scalable, and it's way more difficult than it ought to be!

Anyways...

The client has to be multithreaded. If you're on unix, look into pthreads, otherwise look on msdn. I have quite a bit of experience if you need some specific help.

[sohguanh]

A server run on the server side spawns a new thread for every connection.
NOOOO000ooooooooo!!!! I wasted sooo much time on blocking sockets with hundreds of threads. In the beginning it's fine, but it's not scalable, and it's way more difficult than it ought to be!

Most developers adopt the pool concept. A pool of threads instead of spawning threads for every connection only for it to "die off" after finish processing. With a pool, it is available to service other request again.

Analogy is like supermarket cashiers. Usually they open a few lanes for cashiers to do work. The cashier will service multiple customers and not just one customer close counter to open the counter to service the next customer.

[coder777]

ultifinitus wrote:

NOOOO000ooooooooo!!!! I wasted sooo much time on blocking sockets with hundreds of threads. In the beginning it's fine, but it's not scalable, and it's way more difficult than it ought to be!

Is there any better way to do it? What do you mean by not scalable?

You get a new socket for each connection hence no blocking is required. And the thread ends when the task is done.

sohguanh wrote:

Most developers adopt the pool concept. A pool of threads instead of spawning threads for every connection only for it to "die off" after finish processing. With a pool, it is available to service other request again.

Is there really a noticeable advantage?

[sohguanh]

Is there really a noticeable advantage?

It depend on situations. If you are talking about database connection the pool concept is needed. Database connections are not "cheap". I would believe sockets are "precious" resources too so a pool concept is needed.

For less stringent requirements depending on your system, a pool of plain C++ objects sound a luxury or maybe not? :P

[ultifinitus]

A pool of threads instead of spawning threads for every connection only for it to "die off" after finish processing

As I understand it, the most efficient way is to have several threads running, an optimal number is typically found. And the threads then request a command from the controller, which receives it's commands from the main thread, which is running on either select or poll. The only time the threads "die off" is when you have very few connections, and they really aren't necessary.

Is there really a noticeable advantage?

A thousand threads blocking uselessly on recv calls? Or several threads that block on queues? I can see a noticeable advantage, a significant one.

[Lv0f92yv]

A thousand threads blocking uselessly on recv calls? Or several threads that block on queues? I can see a noticeable advantage, a significant one.

Good point. I would be interested in learning how this several threads blocking on queues is implemented.

Edit: I take it the client remains how I had described it, spawning a thread that waits for events from the server sent to it?

The server then spawns only a finite number of threads, how do they respond to an undefined number of clients?

[ultifinitus]

The threads will be worker threads, and request a job from the manager, the thread then completes the job, and asks for another.

The general implementation has a dynamic number of worker threads, so as the load gets heavier, the threads spawn as they dwindle so do the threads.

The worker thread itself does not wait for actions from the client, the parent thread does that on a list of file descriptors. When one is ready to read, write, connect, or disconnect, the parent gives those instructions to the manager.