From: Lupe Christoph Date: Mon, 24 Jul 2000 08:59:15 +0000 (+0200) Subject: Document a bit that UDP is not what you might think. X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=90034919d1dc964874dc273f4a7932d9c2d84416;p=p5sagit%2Fp5-mst-13.2.git Document a bit that UDP is not what you might think. Subject: Re: IO::Socket::INET bug sending large UDP packets/fragmentation Message-ID: <20000724085915.B13172@alanya.lupe-christoph.de> p4raw-id: //depot/perl@6534 --- diff --git a/pod/perlipc.pod b/pod/perlipc.pod index 6467a29..47556a5 100644 --- a/pod/perlipc.pod +++ b/pod/perlipc.pod @@ -1246,6 +1246,11 @@ find yourself overly concerned about reliability and start building checks into your message system, then you probably should use just TCP to start with. +Note that UDP datagrams are I a bytestream and should not be treated +as such. This makes using I/O mechanisms with internal buffering +like stdio (i.e. print() and friends) especially cumbersome. Use syswrite(), +or better send(), like in the example below. + Here's a UDP program similar to the sample Internet TCP client given earlier. However, instead of checking one host at a time, the UDP version will check many of them asynchronously by simulating a multicast and then @@ -1296,6 +1301,11 @@ with TCP, you'd have to use a different socket handle for each host. $count--; } +Note that this example does not include any retries and may consequently +fail to contact a reachable host. The most prominent reason for this +is congestion of the queues on the sending host if the number of +list of hosts to contact is sufficietly large. + =head1 SysV IPC While System V IPC isn't so widely used as sockets, it still has some