[newbie] trying socket as a replacement for nc

Chris Angelico rosuav at gmail.com
Fri Dec 13 18:05:45 CET 2013


On Sat, Dec 14, 2013 at 3:57 AM, Grant Edwards <invalid at invalid.invalid> wrote:
> On 2013-12-13, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sat, Dec 14, 2013 at 3:10 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>>> Adding boundaries to a TCP stream achieves the same goal (and isn't
>>> that hard to do), but since there's no standard for it, people keep
>>> having to reinvent it (often badly and always incompaibly).
>>
>> Nearest to a standard would be the way heaps of internet protocols are
>> line-based - SMTP, POP, IMAP, FTP, and to a lesser extent HTTP as
>> well. The end-of-line sequence \r\n delimits messages.
>
> And that works very nicely for things that transport text.  It's easy
> to implement, easy to debug, easy to test.  But, when you need to
> transport binary data, it gets ugly and compatibility problems start
> to arise pretty quickly.
>
> One could also borrow standards from the old-school serial world and
> us the SYN/STX/ETX framing with byte stuffing used by HDLC et al.

Yeah, or if it's a tight binary protocol with occasional bits of
bigger payload, either MIDI or TELNET could offer ideas. MIDI's SysEx
message can carry whatever is needed of it, and TELNET has
subnegotiation that can be used for the odd thingy or so. But for a
generic binary stream-of-messages pipe (as opposed to the
stream-of-bytes pipe that TCP normally offers), probably the easiest
is to precede each write with an N-byte length... and somehow
negotiate what N should be. (And endianness, but hopefully that's just
network byte order.)

Standards are awesome, there are so many to choose from! http://xkcd.com/927/

ChrisA



More information about the Python-list mailing list