Re: Something like "ping" for windows messages.

CSocket is blocking, and is reported to have numerous bugs. I wouldn't know, I wouldn't
use it for anything. CAsyncSocket works very well. Programming raw sockets is only for
people who enjoy pain and suffering and feel that it improves them. I can generally throw
together an asynchrous socket server from memory these days, with a 90% chance that I've
remembered all the parameters to all he methods and got them in the right order. It just
isn't all that hard to create asynchronous servers with CAsyncSocket.

Sometimes I put all the socket processing in a separate (UI) thread, and sometimes I leave
it in the main GUI thread. But if there's any serious work to do to handle the message, I
do it in server threads, and I use some form of queueing to create items to be processed.
My favorite queueing mechanism is I/O Completion Ports, followed closely by PostMessage.

I was going to point out that listen() doesn't block at all; you're thinking of accept(),
but I see you caught that.
joe

On Sun, 10 Dec 2006 08:17:06 -0800, Geoff <geoff@xxxxxxxxxxxxxxx> wrote:

On 10 Dec 2006 01:54:47 -0800, "Peter Smithson" <Peter_Smithson@xxxxxxxxxxx>
wrote:


Geoff Joy wrote:
If you are using MFC then it is not Win16, the old code might have been Win16
but you have now stepped outside that paradigm. Sending yourself WM_TIMER
messages was a way of assuring a message would arrive for your application in
Win16 since GetMessage was a yield of CPU to the OS. I suspect the original
application may have had some kind of polling it was doing, hence the timer.

Correct.

There are also some
issues to be aware of, depending on if you are using CSocket or CAsyncSocket.
Refer to the experts in winsock for advice there.

I've read a faq somewhere on sockets that wasn't very complementary
about CSocket. In this case, the server is using CAsyncSocket but the
article wasn't too happy about that either! In the past I've always
used Win32/socket calls and many threads so I'm on a learning curve
with MFC classes.

There were issues with both of them and I can't remember the specifics now, but
I am an old-schooler so I use the bare WS2 stuff. :)


The HTTP server portion should run in it's own thread if you think it will impact the message pump.

I'm 99% sure a thread would help. Just trying to get a rough idea of
what the benefit might be and, if I did the work, if I helped matters.
Threads are great but I've found that adding them to a design after the
event can cause lots of headaches - lots of thread unsafe code around
sometimes. Those kinds of bugs are nasty to track down. So I only use
them when I know they're of benefit.

Use NETMON to sniff the wire to measure the latency in your TCP server.

This might help your probing:

Try starting the performance timer at the end of the message loop and stopping
at the start (with appropriate trapdoors of course) to see how long your process
was suspended. I have tested this in a simple hello world application and when
there are no messages the message loop remains idle and the idle time is
recorded by the timer when the next message arrives. (Mouse moves are 10ms, the
smallest message interval I saw was 16uS.)

I think I see what you're saying. My MFC knowledge is fairly basic.
How would I insert this code in the message loop? Isn't that hidden
away in the MFC library? If you have a simple hello world demo to hand
then perhaps that'd explain it best. My e-mail address is Peter dot
Smithson at gmail.com. Thanks.

I recommend letting the HTTP server idle out with no connections and see if it
blocks the message loop.

I'm not sure I've understood you there. If the http server isn't doing
anything then I'd have thought I'd be 100% gaurenteed that there'd be
no message loop being blocked. This http server is already built into
our server and the server certainly still works when there are no http
requests.


I wasn't sure if you were using the wrapped sockets (C(Async)Socket) or if you
were coding closer to the old WS-API so I was not certain the listen() would
block your application or not. Looking at the socket functions list now, it's
accept() that can block, not listen(). If it doesn't block then your message
loop is fine.

Does the application have an About box or modal dialogs? If so, watch out for
what happens to the message loop when the dialog is up.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: CAyncSocket horrible?
    ... What about CAsyncSocket would make it "a poor design choice" for 100+ ... The key issues for a high-load server are efficient socket event ... GUI apps that also manage several sockets. ...
    (microsoft.public.vc.mfc)
  • Re: Sockets dont close
    ... methodology, no matter how good its reference implementation, isn't going to help. ... and CAsyncSocket aren't available, they are the first places I'd look for an asynchronous ... I wouldn't attempt to build a server using blocking sockets. ...
    (microsoft.public.vc.mfc)
  • Re: CAyncSocket horrible?
    ... What about CAsyncSocket would make it "a poor design choice" for 100+ users? ... It is likely that IIS and SQLServer use IOCP and thread pools for their sockets. ... The key issues for a high-load server are efficient socket event detection and scalability. ... But it is not the best design choice for managing many active sockets in a server. ...
    (microsoft.public.vc.mfc)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... client ... No bollocks HTTP, SOAP, XML, Java, Garbage ... receive messages from any number of server processes who in turn could be ... Unlike TCP/IP and/or UDP Sockets with Java that have been around since ...
    (comp.os.vms)
  • Example: Socket code (Was Re: ClientServer App)
    ... protocol, such as HTTP, as your application middleware backbone?". ... control of the server with Flash Data Management Services?" ... just enter an asterix "*" for the Queue Name and then click ... thought was to use sockets with xml-rpc but then thought there has to ...
    (comp.lang.java.programmer)
Loading