C / C++ / MFC

Nemanja Trifunovic wrote:

but most of user-space code (shell, etc) is C++

Zac Howland wrote:

When you browse through MSDN looking at Win32 API documents (not MFC documents), you'll notice that there are no classes defined -- only structs defined in old-style C syntax. This is also why all window/threading/event API calls take a handle as the first paramter.

Nemanja Trifunovic wrote:

That really shows nothing. It is easy to make a C interface to a C++ implementation.

Zac Howland wrote:

Yes, because in 1997 when the Win2K OS was being designed, Microsoft had enough forethought to implement the OS in C++ (which hadn't even been standardized yet) and then took the extra time to wrap the entire OS with a pure C API ... and then provided yet another wrapper around the C API written in C++ (which is known as MFC).

Nemanja Trifunovic wrote:

Again, they may be lying

Zac Howland wrote:

Typically, the way I set up my server is to have 1 listening thread and either 1 thread per connection, or 1 thread for all connections (depending on the amount of traffic I intend to be sending/receiving).

Zac Howland wrote:

The option with 1 thread per connection would be using a thread pool.

Zac Howland wrote:

You said this is for MC (multicast?) programming?

CMas07 wrote:

As for the other points you made, I need to have the client wait for a response from the server after sending information (thus why I wanted to make it synchronous). The big problem is that on the server side, I need it to have as few threads as possible while it listens for connections and sends/receives data to and from the clients.

<br />
//receives the connection confirmation<br />
recvd = Client->Receive(recBuff, 512, 0);<br />
		<br />
//prints said confirmation	<br />
for(int i = 0; i < recvd; i++)<br />
	cout << recBuff[i];						<br />
cout << endl;<br />
<br />
while(true) {<br />
	//gets user input<br />
	cout << "Next Message:  ";<br />
	string message = "";<br />
	cin >> message;							<br />
	cout << message << endl;<br />
			<br />
	if(message == "quit") {<br />
		Client->Send(message.c_str(), message.length(), 0);<br />
		break;<br />
	}<br />
	else<br />
	{<br />
		//Sends the message to the server<br />
		Client->Send(message.c_str(), message.length(), 0);	<br />
				<br />
		//Breaks here...can't figure out why, <br />
		//but should receive a confirmation <br />
		//that the message was received<br />
		recvd= Client->Receive(recBuff, 512, 0);<br />
				<br />
		//Again, prints the confirmation from the server			for(int i = 0; i < recvd; i++)<br />
			cout << recBuff[i];						cout << endl;<br />
	}<br />
}<br />

<br />
//...code with WSAStartup and the creation of the listening socket,<br />
//through the Listen() call<br />
<br />
//Begins the thread that will receive the messages from the connected<br />
//clients while this one accepts connections.<br />
AfxBeginThread(ReceiveThread, 0);<br />
<br />
sockaddr_in from;<br />
int fromlen=sizeof(from);<br />
	<br />
//Continuously looks for connections to accept.<br />
while(true)<br />
{<br />
	Sleep(1);<br />
<br />
	//Skeleton class the inherits from CAsyncSocket<br />
	AsyncClient AcceptSocket;<br />
	if(ListenSocket->Accept(AcceptSocket, (struct sockaddr*)&from, &fromlen))<br />
	{<br />
		//Adds the newly connected socket to the vector of <br />
		//connected clients<br />
		clients.push_back(&AcceptSocket);<br />
		char buff[512];<br />
		strcpy(buff, "#Server Ready!");<br />
<br />
		//Sends the connection confirmation message to the <br />
		//newly connected client.<br />
		AcceptSocket.Send(buff, strlen(buff), 0);<br />
<br />
		//Simple message confirmation ont he server-side that <br />
		//a connection was accepted.<br />
		cout << "Accepted a connection from ";<br />
		cout << inet_ntoa(from.sin_addr) << endl;<br />
	}<br />
}<br />

CMas07 wrote:

recvd= Client->Receive(recBuff, 512, 0);

//Again, prints the confirmation from the server for(int i = 0; i < recvd; i++)
cout << recBuff[i]; cout << endl;

Zac Howland wrote:

You are not guaranteed to get your entire message at once here. Technically, you should do both send and recv calls in loops until they are completely sent/received.

Zac Howland wrote:

Your connection is being reset because your server socket is going out of scope and closing itself.

Zac Howland wrote:

You should try to spawn a new thread and pass the AcceptSocket as a parameter to it to keep it alive.

CMas07 wrote:

DOH! I should've seen that myself, but I suppose stupidity had set in at that point after hours and hours of frantically searching through my client to catch the non-existent bug.

CMas07 wrote:

However, this would create a thread per client, which is what I was trying to avoid, so I thought storing them in a vector would be able to keep them all alive, and then with the asynchronous server-side it would be able to simultaneously send to and receive from all clients (having the sends and receives each in one different thread to handle them), thus having a total of three threads.

CMas07 wrote:

Again, threading is something that I'm new to as well, so I wasn't sure how that would fair either.

CMas07 wrote:

or at least no more than 3 or so

led mike wrote:

If you are "new to threading" then where does this:

CMas07 wrote:
or at least no more than 3 or so

come from?

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb