diff options
Diffstat (limited to 'docs/tutorials/001/page03.html')
| -rw-r--r-- | docs/tutorials/001/page03.html | 195 |
1 files changed, 0 insertions, 195 deletions
diff --git a/docs/tutorials/001/page03.html b/docs/tutorials/001/page03.html deleted file mode 100644 index 00a8d4c7646..00000000000 --- a/docs/tutorials/001/page03.html +++ /dev/null @@ -1,195 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> -<HTML> -<HEAD> - <TITLE>ACE Tutorial 001</TITLE> - <META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]"> - <META NAME="Author" CONTENT="James CE Johnson"> - <META NAME="Description" CONTENT="A first step towards using ACE productively"> -</HEAD> -<BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> - - -<CENTER><P><B><FONT SIZE=+2>ACE Tutorial 001<BR> -A Beginners Guide to Using the ACE Toolkit</FONT></B></P></CENTER> - -<hr> -<P>Now we begin to look at the <A HREF="acceptor.h">acceptor</A> object. - -<P> -Kirthika has this analogy: -<P> -<UL> -Consider an office: -<P> -Reactor: Receptionist -<P> -Event_Handlers: various Departments catering to specific needs. -<P> -SERVER_PORT: door -<P> -Acceptor: Doorkeeper -<P> -Thus when a needy person (client) enters the open door (port) -maintained by the doorkeeper (acceptor waiting for connection -request), the receptionist(reactor) directs the person towards the -appropriate section (event_handler) which would cater to his needs. -</UL> -<P> -<HR> -<PRE> -<font color=red>// $Id$</font> - -<font color=blue>#ifndef</font> <font color=purple>_CLIENT_ACCEPTOR_H</font> -<font color=blue>#define</font> <font color=purple>_CLIENT_ACCEPTOR_H</font> - -<font color=red>/* A SOCK_Acceptor knows how to accept socket connections. We'll use - one of those at the heart of our Logging_Acceptor. */</font> -<font color=blue>#include</font> "<A HREF="../../../ace/SOCK_Acceptor.h">ace/SOCK_Acceptor.h</A>" - -<font color=blue>#if !defined</font> (<font color=purple>ACE_LACKS_PRAGMA_ONCE</font>) -<font color=blue># pragma</font> <font color=purple>once</font> -<font color=blue>#endif</font> <font color=red>/* ACE_LACKS_PRAGMA_ONCE */</font> - -<font color=red>/* An Event_Handler is what you register with ACE_Reactor. When - events occur, the reactor will callback on the Event_Handler. More - on that in a few lines. */</font> -<font color=blue>#include</font> "<A HREF="../../../ace/Event_Handler.h">ace/Event_Handler.h</A>" - -<font color=red>/* When a client connects, we'll create a Logging_Handler to deal with - the connection. Here, we bring in that declaration. */</font> -<font color=blue>#include</font> "<font color=green>logger.h</font>" - -<font color=red>/* Our Logging_Acceptor is derived from ACE_Event_Handler. That lets - the reactor treat our acceptor just like every other handler. */</font> -class Logging_Acceptor : public ACE_Event_Handler -{ -public: - - <font color=red>/* For this simple case we won't bother with either constructor or - destructor. In a real application you would certainly have them. */</font> - - <font color=red>/* Here's the open() method we called from main(). We have two - things to accomplish here: (1) Open the acceptor so that we can - hear client requests and (2) register ourselves with the reactor - so that we can respond to those requests. */</font> - int open (const ACE_INET_Addr &addr, - ACE_Reactor *reactor) - { - <font color=red>/* Perform the open() on the acceptor. We pass through the - address at which main() wants us to listen. The second - parameter tells the acceptor it is OK to reuse the address. - This is necessary sometimes to get around closed connections - that haven't timed out. */</font> - if (this->peer_acceptor_.open (addr, 1) == -1) - return -1; - - <font color=red>/* Remember the reactor we're using. We'll need it later when we - create a client connection handler. */</font> - reactor_ = reactor; - - <font color=red>/* Now we can register with the reactor we were given. Since the - reactor pointer is global, we could have just used that but it's - gross enough already. Notice that we can pass 'this' right into - the registration since we're derived from ACE_Event_Handler. We - also provide ACCEPT_MASK to tell the reactor that we want to - know about accept requests from clients. */</font> - return reactor->register_handler (this, - <font color=#008888>ACE_Event_Handler::ACCEPT_MASK</font>); - } - -private: - - <font color=red>/* To provide multi-OS abstraction, ACE uses the concept of - "<font color=green>handles</font>" for connection endpoints. In Unix, this is a - traditional file descriptor (or integer). On other OS's, it may - be something else. The reactor will need to get the handle (file - descriptor) to satisfy it's own internal needs. Our relevant - handle is the handle of the acceptor object, so that's what we - provide. */</font> - ACE_HANDLE get_handle (void) const - { - return this->peer_acceptor_.get_handle (); - } - - <font color=red>/* When an accept request arrives, the reactor will invoke the - handle_input() callback. This is where we deal with the - connection request. */</font> - virtual int handle_input (ACE_HANDLE handle) - { - <font color=red>/* The handle provided to us by the reactor is the one that - triggered our up-call. In some advanced situations, you might - actually register a single handler for multiple connections. - The _handle parameter is a way to sort 'em out. Since we don't - use that here, we simply ignore the parameter with the - ACE_UNUSED_ARG() macro. */</font> - ACE_UNUSED_ARG (handle); - - Logging_Handler *svc_handler; - - <font color=red>/* In response to the connection request, we create a new - Logging_Handler. This new object will be used to interact with - the client until it disconnects. Note how we use the - ACE_NEW_RETURN macro, which returns -1 if operator new fails. */</font> - ACE_NEW_RETURN (svc_handler, - Logging_Handler, - -1); - - <font color=red>/* To complete the connection, we invoke the accept() method call - on the acceptor object and provide it with the connection - handler instance. This transfers "<font color=green>ownership</font>" of the connection - from the acceptor to the connection handler. */</font> - if (this->peer_acceptor_.accept (*svc_handler) == -1) - ACE_ERROR_RETURN ((LM_ERROR, - "<font color=green>%p</font>", - "<font color=green>accept failed</font>"), - -1); - - <font color=red>/* Again, most objects need to be open()ed before they are useful. - We'll give the handler our reactor pointer so that it can - register for events as well. If the open fails, we'll force a - close(). */</font> - if (svc_handler->open (reactor_) == -1) - svc_handler->close (); - - return 0; - } - -protected: - - <font color=red>/* Our acceptor object instance */</font> - ACE_SOCK_Acceptor peer_acceptor_; - - <font color=red>/* A place to remember our reactor pointer */</font> - ACE_Reactor *reactor_; -}; - -<font color=blue>#endif</font> <font color=red>/* _CLIENT_ACCEPTOR_H */</font> - -</PRE> -<HR WIDTH="100%"></PRE> -It is important to notice here that we have done very little application-specifc -code in developing this object. In fact, if we take out the progress information, -the only app-specific code is when we create the new <I>Logging_Handler</I> -object to give to the <I>accept</I> function. You may begin to wonder why -there isn't a C++ template that does all of this coding for you. Actually, -the ACE toolkit happens to have one handy: -<UL>typedef ACE_Acceptor <<I>YourHandlerClass</I>, ACE_SOCK_ACCEPTOR> -<I>YourAcceptorClass</I>;</UL> -We would have used it like this: -<UL>typedef ACE_Acceptor <Logging_Handler, ACE_SOCK_ACCEPTOR> Client_Acceptor;</UL> -This will create a piece of code similar to what I've shown above. The -primary difference is that the <I>handle_input </I>function created by -the template does NOT register the handler with the reactor. In the long-run, -that is good for us because we can then move that logic into the <I>open</I> -function of the <I>Logging_Handler</I> and use a completely-generic acceptor. - -<P>Now that we know how to accept a connection request, let's move on to -the next page where we learn how to handle the actual connection. Even -though we just learned about this cool template thing, we will continue -to use the "hand-written" acceptor developed above. As I mentioned, the -only difference will be in the <I>open</I> function of the connection handler -anyway. - -<P> -<P><HR WIDTH="100%"> -<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page04.html">Continue This Tutorial</A>]</CENTER> |