diff options
Diffstat (limited to 'docs/tutorials/008/page02.html')
| -rw-r--r-- | docs/tutorials/008/page02.html | 173 |
1 files changed, 0 insertions, 173 deletions
diff --git a/docs/tutorials/008/page02.html b/docs/tutorials/008/page02.html deleted file mode 100644 index 1b5b79c19a2..00000000000 --- a/docs/tutorials/008/page02.html +++ /dev/null @@ -1,173 +0,0 @@ -<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> "<font color=green>ace/SOCK_Dgram.h</font>" -<font color=blue>#include</font> "<font color=green>ace/INET_Addr.h</font>" - -<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[512]; - - <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,strlen(buf)+1,remote) == -1 ) - { - ACE_ERROR_RETURN ((LM_ERROR, "<font color=green>%p\n</font>", "<font color=green>send</font>"),-1); - return(0); - } - } - - 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> |