CSocket
in [MFC]
|
From: "Bill Brehm" <<don't want any on 16 Dec 2005 02:09 Lol. Thanks. I guess that means CAsyncSocket really can't be used as is and it must be derived from to be useful. I wonder why they didn't make OnReceive() pure virtual to force one to override it. Oh, I guess CAsyncSocket could be used if Receive() is just polled for data. Anyway... Some more questions. 1. When OnAccept() or On Receive() are called, are they running in the main application's thread or do they run in a separate thread? It looks like a new thread is started when a socket is told to listen. Does it send a message to the main thread that ends up being translated into a call to OnAccept(), etc? 2. When I derive from CAsyncSocket() and try to Connect(), I get an error that it would block (WSAEWOULDBLOCK). Yet it seems to work okay to be accepted and receive the data. Can I just ignore the error? (I don't get the error when I tested with deriving from CSocket.) 3. I'm confused about Accept(). I have to pass in a new socket reference. Is that so the original socket stays open and listening so it can effectively accept many connections? If I only want to have one connection what do I do? Accept with a reference to itself? Or just refuse to accept new connection attempts? 4. Last question is about the application. Mine is a dialog based MFC app. Then I derived a CMySocket from CAsyncSocket. I want CMySocket to be reusable without changes. My problem is with OnAccept() and OnReceive(). OnReceive() needs access to a buffer and in may need to trigger something to be done with the data, such as writing it to a control on the dialog. What is the correct way to get the dialog to know about the call to OnReceive() and process the data? Should it just send a message to the main app and then whichever app uses CMySocket needs to expect and handle that message? If yes, how do I define a message ID in CMySocket that will be guaranteed not to conflict with another in future apps that use this class. OnAccept() has a related issue. I assume the new socket that I must pass into Accept() should belong up at the app level, not inside this class. So I need to trigger the app someway to do the actual accepting. I look in the example program Chatsrvr and the derived socket class gets a pointer to a CDocument. But I don't like that because the next application may not be a document - view app. Thanks... "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:O6%23R$vXAGHA.3048(a)TK2MSFTNGP15.phx.gbl... > Bill Brehm < wrote: >> What does OnReceive() do if it is not overridden? >> > > Nothing. > > -- > Scott McPhillips [VC++ MVP] >
From: Scott McPhillips [MVP] on 16 Dec 2005 08:13 Bill Brehm < wrote: > Lol. Thanks. I guess that means CAsyncSocket really can't be used as is and > it must be derived from to be useful. I wonder why they didn't make > OnReceive() pure virtual to force one to override it. Oh, I guess > CAsyncSocket could be used if Receive() is just polled for data. Anyway... > > Some more questions. > > 1. When OnAccept() or On Receive() are called, are they running in the main > application's thread or do they run in a separate thread? It looks like a > new thread is started when a socket is told to listen. Does it send a > message to the main thread that ends up being translated into a call to > OnAccept(), etc? Everything runs in the main thread (actually, the thread that called Create). The OnXxxxx virtual functions are message handlers, just like mouse and button click handlers. > 2. When I derive from CAsyncSocket() and try to Connect(), I get an error > that it would block (WSAEWOULDBLOCK). Yet it seems to work okay to be > accepted and receive the data. Can I just ignore the error? (I don't get the > error when I tested with deriving from CSocket.) WSAEWOULDBLOCK is not really an error, it is a normal part of working with CAsyncSocket. The way it avoids blocking your program is to return WSAEWOULDBLOCK when results are not immediately available. You program goes on about its business, then when the results are available later you get a call to OnConnect. > > 3. I'm confused about Accept(). I have to pass in a new socket reference. Is > that so the original socket stays open and listening so it can effectively > accept many connections? If I only want to have one connection what do I do? > Accept with a reference to itself? Or just refuse to accept new connection > attempts? > Yes, the original socket (in a server) should stay listening. If you don't want to accept an incoming request don't call Accept. > 4. Last question is about the application. Mine is a dialog based MFC app. > Then I derived a CMySocket from CAsyncSocket. I want CMySocket to be > reusable without changes. My problem is with OnAccept() and OnReceive(). > OnReceive() needs access to a buffer and in may need to trigger something to > be done with the data, such as writing it to a control on the dialog. What > is the correct way to get the dialog to know about the call to OnReceive() > and process the data? Should it just send a message to the main app and then > whichever app uses CMySocket needs to expect and handle that message? If > yes, how do I define a message ID in CMySocket that will be guaranteed not > to conflict with another in future apps that use this class. OnAccept() has > a related issue. I assume the new socket that I must pass into Accept() > should belong up at the app level, not inside this class. So I need to > trigger the app someway to do the actual accepting. I look in the example > program Chatsrvr and the derived socket class gets a pointer to a CDocument. > But I don't like that because the next application may not be a document - > view app. > > Thanks... Virtual functions will let you keep your CMySocket class free of dependencies on the caller. Each user of CMySocket derives an interface class from CMySocket. A particular interface class will contain a pointer to the dialog or whatever, and forward each virtual call to the dialog. This pattern will not only let you use CMySocket in other projects, it will also let a single app use multiple instances of CMySocket, on multiple ports, from multiple threads, etc. -- Scott McPhillips [VC++ MVP]
First
|
Prev
|
Pages: 1 2 3 Prev: draw text on a cimage Next: error LINK2019: unresolved external symbol |