Re: Newcomer's CAsyncSocket example: trouble connecting with other clients

See below...
On Thu, 13 May 2010 15:22:04 -0700 (PDT), stephen park <steebu@xxxxxxxxx> wrote:

On May 13, 2:23 pm, Hector Santos <sant9...@xxxxxxxxx> wrote:

It does work. That is why I gave you other host names and ports to try
it.  Its a simple "Dump Terminal" client application.

Not sure what exactly you are looking for?  How to make Joe's code work?

Yeah, ok, I guess let me explain it this way.

Assumption: The Newcomer server works. Meaning, I can send it
messages using either the Newcomer client or other client examples
I've found. And note, I'm making an assumption, so I could be wrong
and it does NOT handle incoming messages on a particular TCP port, but
all experiments seem to indicate it works just fine.
My server works but ONLY if you conform to its protocol requirement, if you used the code
exactly. This means the first 4 bytes of every message must be the length of the message
text. If you are not sending this, the server, if you are using my code verbatim, will
not work correctly.

So, with the assumption in mind, I just want to write my own command
line client that connects to the server and sends a message like, "Hi
there!" which will display the received text. So far, using csocket,
casyncsocket (with a gui), or TcpClient, has not worked.

Assumption: I am doing something wrong. Obviously!

But, what is frustrating (and this is not directed at anyone here,
because you've all been very helpful) is that when I build my own
command-line socket message sender using csocket or TcpClient, it
doesn't work. And I'm either copying your code directly or looking at
other examples on MSDN or elsewhere. It just plain doesn't work, and
I'm getting very frustrated because it should! Example code on
codemasters and elsewhere I see says, "Just do this!":

// mfc version
CSocket c;
c.Connect( server, ip );
c.Send( data ); // can't remember the exact syntax, but you get the
Actually, this is not formally correct, because (a) it uses CSocket, which has serious
problems and (b) it does not do a Shutdown, which means that the correct behavior is not
guaranteed by the network stack.

yet, when I run it, nothing gets sent. The server says it got a
connection, then the connection closed. No message was "sent". Was
it lost in the ether? Did the socket shut down without flushing the
buffer? Maybe.
Most likely
But not a single example says I should do that.
Largely because each person copies an example, which has a bug, and the bug propagates to
every site that has the sample, or a derivation of it. The socket specification says that
flushing is not guaranteed on a close() (or closesocket(), in WinSock).
How the heck would I know that I need to do that? Ok, no problem, I'll
flush the buffer by calling shutdown() or even flush(). But that
doesn't work either. So everybody's suggesting things, which again,
is very helpful and great, but nothing is working. Hence ... the
frustration. Again, not directed at anyone (except maybe me).

So, maybe what might help would be if someone could download the
server found here:

and write a simple command-line (.net or mfc) example using csocket or
TcpClient that sends a "hello" message to it. That would actually be
a good start, because if I can't get that to work, then at least I'll
know something else is up (although I've checked firewall settings,
etc.) ...
The correct byte sequence would be the following 9 bytes

'\x05' '\x00' '\x00' '\x00' 'H' 'e' 'l' 'l' 'o'

because that is the protocol I specify and require, if you use my server code verbatim. If
you changed it to use some other protocol, then you need to specify what protocol you are

Every server ever written has a "protocol" that must be followed. Some of these protocols
are specified in RFCs (e.g. Telnet, FTP, Ping, etc.) and some are the invention of the
creator of the server; mine is the latter.

And why wouldn't I use the async client found on the newcomer page?
Well, first off, I'd like to keep it really simple. I don't need to
use threads or anything, nor do I need to use a GUI. So, that kinda
rules out using casyncsocket. Surely this can be done!
My core example was multithreaded sockets, but you can eliminate the multithreading. It
was done in response to the unbelievably horrible example that Microsoft wrote, which
killed at least one major project a company was doing. Such slovenliness is inexcusable
(essentially, they got sockets, threading, and synchronization wrong). I built it to use
a GUI interface because I wrote it to run in a pure-MFC environment and therefore could
add a GUI to make it easy to demonstrate how it worked. The idea was that if you don't
need multithreading, if you don't need a GUI, you should subset it, and you have to design
your own protocol if you don't like mine (which is a pretty standard-vanilla protocol, by
the way).

Densely yours, and thanks everyone for the suggestions to a socket
noob ...

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
MVP Tips: