Re: Compiling to a single exe file

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 03/07/04 

Date: Sun, 07 Mar 2004 15:41:44 -0500

Well, one fundamental mistake you made is to do == TRUE. NEVER write == TRUE for a test. A
boolean result stands for itself (never write == FALSE either). Note that the
specification now says "returns a nonzero value", meaning it can return anything it feels
like, but you require a very specific nonzero value, TRUE. So this code is extremely
dangerous.

As I've read this cut-down example, you open a socket, accept one connection, process the
requests, and exit the loop (it is hard to read with all the braces misaligned). Also, you
seem to allow at most one backlogged connection, which seems a bit restrictive.

This is an iterative server, a rather unnatural paradigm for TCP servers because it means
you can only process one request at a time. This is why it seems odd to have limited the
number of pending requests to just 1. Then you exit the thread, which destroys the
listening port (unless this is just a superficial side effect of the cut-down example).

Rather than using a lot of nested ifs, it is usually cleaner to use a rule-based model
(yes, I know, there are a lot of religious fanatics about "only one return point in a
function". I am more suspicious of code that is in the rightmost inch of the screen,
becaue it is difficult to unwind the preconditions of the innermost nesting, and it
usually takes a complete rewrite if there are changes in the preconditions...the same
failure as the old "top-down programming" model had over, say, modular decomposition)

CSocket hostSock;
if(!hostSock.Create(IVHOST_LISTENING_PORT))
      return 0; // failed
if(!hostSock.Listen())
     return 0; // failed
// all necessary preconditions are met
while(true)
   {
     CSocket client;
     if(!hostSock.Accept(client))
        break; // accept failed
     .... process client requests
   }

Now in your example below, or the example above, can you indicate where the access fault
takes place? For example, you should have a traceback to the place in this collection of
code where the error occurs. Note that it is critical to indicate any other MFC objects
that might be allocated/deallocated, because when you have a statically-linked library, it
could be that completely unrelated allocations are going on, and you are seeing not a
result of socket confusion, but the consequence of some value in one heap being freed into
another heap. You have also not said if there are any other non-Microsoft MFC-based DLLs
involved in this program (e.g., do you call a DLL you wrote or are using from inside your
loop?)
                                joe

On Sun, 7 Mar 2004 22:06:28 +0500, "adeel" <anonymous@discussions.microsoft.com> wrote:

>Here's the code.......
>[code]
>
>UINT serverProc (LPVOID pParam)
>
>{
>
>CSocket hostSock;
>
>// Creating the host socket and setting it up to listen for connection
>attempts.
>
>if (hostSock.Create(IVHOST_LISTENING_PORT) == TRUE) {
>
> if (hostSock.Listen(1) == TRUE) {
>
>
> while (true) {
>
> CSocket client;
>
> if (hostSock.Accept(client) == TRUE) {
>
>
> // Process client requests here.
>
> client.Receive (buffer, 512);
>
> }
>
> break;
>
> } // end of while
>
> }
>
>return 0;
>
>}
>
>[/code]
>
>
>
>There probably is nothing wrong with the code itself.... it works well when
>MFC is being used as a shared dll. The access violation comes up only when I
>use MFC as a statically linked library......
>
>
>
>"adeel" <anonymous@discussions.microsoft.com> wrote in message
>news:O%23u7s1%23AEHA.3184@TK2MSFTNGP09.phx.gbl...
>> The error is a runtime access violation....... there's no time to call
>> GetLastError. That is, the debugger sticks at the socket 'Create' call and
>> refuses to step forward!
>>
>>
>> "Jase" <jshelley@nospam.optushome.com.au> wrote in message
>> news:404a8a09$0$3955$afc38c87@news.optusnet.com.au...
>> > "adeel" <anonymous@discussions.microsoft.com> wrote in message
>> > news:OUVmHY#AEHA.1212@TK2MSFTNGP12.phx.gbl...
>> > > Thanks to both of you for replying.....
>> > >
>> > > If the static linking is the only way to do this........ then I guess
>> I'm
>> > > back to the issue I posted a few days ago (which was about getting
>these
>> > > runtime errors).
>> > >
>> > > I'm not making any cross-thread socket calls (have learned a good
>leason
>> > to
>> > > avoid that!). The socket is created inside the thread that I want to
>use
>> > it
>> > > in........ but the create call fails due to some unknown (to me)
>reason.
>> > >
>> > > I wonder what I'm doing wrong :(
>> > [snip]
>> >
>> > What does GetLastError() return? Your answers almost surely there.
>> >
>> > Jase
>> >
>> >
>>
>>
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm