[newbie] trying socket as a replacement for nc

[88888 Dihedral]

On Friday, December 13, 2013 5:58:49 AM UTC+8, Chris Angelico wrote:
> On Fri, Dec 13, 2013 at 8:27 AM, Dan Stromberg <drsalists at gmail.com> wrote:
> 
> > On Thu, Dec 12, 2013 at 6:16 AM, Grant Edwards <invalid at invalid.invalid> wrote:
> 
> >
> 
> >>> Sockets reserve the right to split one socket.send() into multiple
> 
> >>> socket.recv()'s on the other end of the communication, or to aggregate
> 
> >>> multiple socket.send()'s into a single socket.recv() - pretty much any way
> 
> >>> the relevant IP stacks and communications equipment feel like for the sake
> 
> >>> of performance or reliability.
> 
> >>
> 
> >> Just to be pedantic: _TCP_ sockets reserver that right.  UDP sockets
> 
> >> do not, and do in fact guarantee that each message is discrete.  [It
> 
> >> appears that the OP is undoubtedly using TCP sockets.]
> 
> >
> 
> > I haven't done a lot of UDP, but are you pretty sure UDP can't at
> 
> > least fragment large packets?  What's a router or switch to do if the
> 
> > Path MTU isn't large enough for an original packet?
> 
> >
> 
> > http://www.gamedev.net/topic/343577-fragmented-udp-packets/
> 
> 
> 
> I'm no expert on this (mostly I do TCP, or UDP with fairly small
> 
> packets), but the packet should be reassembled at the far end. When
> 
> your application comes to receive it, it'll receive the entire UDP
> 
> packet as a whole.
> 
> 
> 
> UDP fragmentation has several problems. First, if any fragment is
> 
> lost, it won't be retransmitted (as TCP will), so the whole datagram
> 
> is lost. And secondly, if you stream data across the network in a
> 
> series of packets just a little too large to fit, each one will get
> 
> split in two and you'll end up with twice as many packets going out,
> 
> ergo abysmal performance. With TCP, there's the chance that the sender
> 
> and receiver can between them figure out what packet size to use (cf
> 
> path MTU discovery), but that won't happen with UDP unless the
> 
> application consciously does it. So it's something to be cautious of
> 
> in terms of performance, but if you want to send large UDP packets
> 
> because they make sense, just go ahead and do it.
> 
> 
> 
> Now, if you want reliability AND datagrams, it's a lot easier to add
> 
> boundaries to a TCP stream (sentinel or length prefixes) than to add
> 
> reliability to UDP...
> 
> 
> 
> ChrisA
It is trivial to use UDP with 
forward error correction such as 
the CD in 1982.