After sending 'quit' to smtp-server, it closes connection, and I get a WS_CLOSE message.
I close my socket, and create a new socket and connect to the server again.
It sucks.
Besides occasionaly doesnt work.
But if I try connect again with the same socket that got the WS_CLOSE message, it never works.
Why is this, and what's the right action? :confused:
Posted on 2002-10-29 17:03:07 by david
Originally posted by david
After sending 'quit' to smtp-server, it closes connection, and I get a WS_CLOSE message.
I close my socket, and create a new socket and connect to the server again.
It sucks.

Why? It can't be that bad.. Besides, I don't think it's possible to reuse sockets. When it's shutdown, connect doesn't have to succeed on the same socket handle.

Besides occasionaly doesnt work.
But if I try connect again with the same socket that got the WS_CLOSE message, it never works.
Why is this, and what's the right action? :confused:

AFAIK the right way is to shutdown the socket properly (see the winsock FAQ or PSDK on 'shutdown'), close it and create a new socket.

Thomas
Posted on 2002-10-29 17:14:59 by Thomas
Ahhh....ok. I wasn't so far off as I thought then. :)
Perhaps there's something else I did wrong, I will check my code again.
Thanks Thomas.
Posted on 2002-10-29 17:41:03 by david
I can shed some light here.
I know, everyone tells you to kill the sockethandle and make a new one.

You *CAN* re-use the socket.
But you *CANNOT* call Connect from inside the socket message handler for FD_CLOSE, and that's the issue you are having.


To get around it, one way is to send from the FD_CLOSE handler a WM_MYMESSAGE custom message to your main window, and then have a WM handler for it which (re)connects.
Now you can also have your Connect button just send one of these in the first place to initiate the first connection.
You should also use a flag to PREVENT reconnecting when you actualy wish to end the session, or it will keep reconnecting by itself!

There's variations on this idea which don't generate WM's but for a lightweight application this one works wonderfully.
Posted on 2002-11-01 09:11:21 by Homer
Aha! Thanks a lot!
*copying your reply to a textfile for reference*
:)
Posted on 2002-11-01 16:30:02 by david
why a custom message makes it?
is there docs about it?
Posted on 2002-11-10 20:43:17 by baumann
No documentation, that's just the solution I found myself when I encountered this problem. An alternative is to (1)use a flag, and to monitor it from the main program message loop, another is to (2)set up a thread which waits on an event object, and then triggering that event from the FD message handler, and yet another is to (3)use network event objects (winsock2) which is similar but winsock triggers them for us.
There's 1001 ways to skin a cat, as they say.
The solution I described is probably the easiest to implement.
The problem itself I've never seen documented outside this forum.
Languages like VB don't suffer from this problem as they are generally heavily object-based, and internally rely on event objects and operate on the notion of "sinking and sourcing" of event-triggers.
Learn about event objects and network event objects.
Learn how to code a "sleeper" thread.
These are the more sturdy and scalable solutions to this issue.
Flag-monitoring is not as robust, especially for multiple sockets.
Windows Message solution is likewise not recommended for multiple sockets, because ultimately you will generate a lot of WM's, lagging the main app... but normally it's ok for a single socket unless it's working really hard.
If you wish to prototype an idea on a single socket, the WM solution is ok.
If you then wish to make that solid as a rock and scalable, consider the above.
Posted on 2002-11-10 23:22:37 by Homer