diff options
Diffstat (limited to 'docs/tutorials/008/page02.html')
| -rw-r--r-- | docs/tutorials/008/page02.html | 161 |
1 files changed, 0 insertions, 161 deletions
diff --git a/docs/tutorials/008/page02.html b/docs/tutorials/008/page02.html deleted file mode 100644 index 9d65274f846..00000000000 --- a/docs/tutorials/008/page02.html +++ /dev/null @@ -1,161 +0,0 @@ -<!-- $Id$ --> -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; Linux 2.0.32 i486) [Netscape]"> - <META NAME="Author" CONTENT="James CE Johnson"> - <TITLE>ACE Tutorial 008</TITLE> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F"> - -<CENTER><B><FONT SIZE=+2>ACE Tutorial 008</FONT></B></CENTER> - -<CENTER><B><FONT SIZE=+2>Sending and receiving datagrams</FONT></B></CENTER> - - -<P> -<HR WIDTH="100%"> - - -<P>The first thing we want to look at is <A HREF="server.cpp">server.cpp</A>. -This is a pretty simple application that listens for datagrams at a known -port and sends back a response. In order to implement a true "discovery" -mechanism, the server will have to be a little bit more picky about who -it responds to. We'll tackle that issue in the next tutorial though... - -<P> -<HR WIDTH="100%"> -<PRE> -<font color=red>// $Id$</font> - -<font color=red>/* Our datagram server will, of course, need to create a datagram. - We'll also need an address object so that we know where to listen. */</font> -<font color=blue>#include</font> "<A HREF="../../../ace/SOCK_Dgram.h">ace/SOCK_Dgram.h</A>" -<font color=blue>#include</font> "<A HREF="../../../ace/INET_Addr.h">ace/INET_Addr.h</A>" - -<font color=red>/* Use the typical TCP/IP port address for receiving datagrams. */</font> -static const u_short PORT = ACE_DEFAULT_SERVER_PORT; - -int -main (int, char**) -{ - <font color=red>/* This is where we'll listen for datagrams coming from the clients. - We'll give this address to the open() method below to enable the - listener. */</font> - ACE_INET_Addr local (PORT); - - <font color=red>/* A simply constructed datagram that we'll listen with. */</font> - ACE_SOCK_Dgram dgram; - - <font color=red>/* Like most ACE objects, the datagram has to be opened before it - can be uses. Of course, -1 on failure. - - A datagram will fail to open if there is already a datagram - listening at the port we've chosen. It *is* OK to open a datagram - at a port where there is an ACE_SOCK_Stream though. This is - because datagrams are UDP and SOCK_Stream is TCP and the two don't - cross paths. */</font> - if (dgram.open (local) == -1) - ACE_ERROR_RETURN ((LM_ERROR, - "<font color=green>%p\n</font>", - "<font color=green>open</font>"), - -1); - - <font color=red>/* Create a simple buffer to receive the data. You generally need - to provide a buffer big enough for the largest datagram you expect - to receive. Some platforms will let you read a little and then - some more later but other platforms will throw out whatever part - of the datagram you don't get with the first read. (This is on a - per-datagram basis BTW.) The theoretical limit on a datagram is - about 64k. The realistic limit (because of routers & such) is - much smaller. Choose your buffer size based on your application's - needs. */</font> - char buf[BUFSIZ]; - - <font color=red>/* Unlike ACE_SOCK_Stream, datagrams are unconnected. That is, - there is no "<font color=green>virtual circuit</font>" between server and client. Because - of this, the server has to provide a placeholder for the OS to - fill in the source (client) address information on the recv. You - can initialize this INET_Addr to anything, it will be overwritten - when the data arrives. */</font> - ACE_INET_Addr remote; - - ACE_DEBUG ((LM_DEBUG, - "<font color=green>(%P|%t) starting up server daemon\n</font>")); - - <font color=red>/* Receive datagrams as long as we're able. */</font> - while (dgram.recv (buf, - sizeof (buf), - remote) != -1) - { - <font color=red>/* Display a brief message about our progress. Notice how we - use the 'remote' object to display the address of the client. - With an ACE_SOCK_Stream we used get_remote_addr() to get the - address the socket is connected to. Because datagrams are - unconnected, we use the addr object provided to recv(). */</font> - ACE_DEBUG ((LM_DEBUG, - "<font color=green>(%P|%t) Data (%s) from client (%s)\n</font>", - buf, - remote.get_host_name ())); - - <font color=red>/* To respond to the client's query, we have to become a client - ourselves. To do so, we need an anonymous local address from - which we'll send the response and a datagram in which to send - it. (An anonymous address is simply one where we let the OS - choose a port for us. We really don't care what it is. */</font> - ACE_INET_Addr local ((u_short) 0); - ACE_SOCK_Dgram client; - - <font color=red>/* Open up our response datagram as always. */</font> - if (client.open (local) == -1) - { - ACE_ERROR_RETURN ((LM_ERROR, - "<font color=green>%p\n</font>", - "<font color=green>client open</font>"), - -1); - return 0; - } - - <font color=red>/* Build a witty response... */</font> - sprintf (buf, - "<font color=green>I am here</font>"); - - <font color=red>/* and send it to the client. Notice the symmetry with the - recv() method. Again, the unconnected nature of datagrams - forces us to specify an address object with each read/write - operation. In the case of read (recv()) that's where the OS - stuffs the address of the datagram sender. In the case of - write (send()) that we're doing here, the address is where we - want the network to deliver the data. - - Of course, we're assuming that the client will be listening - for our reply... */</font> - if (client.send (buf, - <font color=#008888>ACE_OS::strlen</font> (buf) + 1, - remote) == -1) - ACE_ERROR_RETURN ((LM_ERROR, - "<font color=green>%p\n</font>", - "<font color=green>send</font>"), - -1); - } - - return 0; -} -</PRE> -<HR WIDTH="100%"> - -<P>And that's really all there is to it. Obviously there is some -room for improvement. The most blatant is the somewhat small buffer -size for receiving the datagram. I've never been able to get a solid -answer on datagram sizes. The theoretical limit is just under 64k -but you have to deal with fragmentation. Some readings indicate that -8k is a reasonable size, others go much smaller. My general rule -of thumb is to keep datagrams relatively small (eg -- under 8k or so) and -test a lot. If you find that your routers are fragmenting your larger -datagrams, back off to something smaller. Of course, if you must -send 100k and can only do so 1k at a time, you'll have to worry about retransmissions -& reordering. At that point, you might consider going to TCP. -Remember: datagrams are unreliable! Don't try to make 'em do -something they werent' designed for! -<P><HR WIDTH="100%"> -<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page03.html">Continue This Tutorial</A>]</CENTER> |