Learning python networking

Dan Stromberg drsalists at gmail.com
Wed Jan 8 18:53:08 EST 2014


Nice response Chris.  Seriously.

On Wed, Jan 8, 2014 at 3:29 PM, Chris Angelico <rosuav at gmail.com> wrote:
> One extremely critical point about your protocol. TCP is a stream -
> you don't have message boundaries. You can't depend on one send()
> becoming one recv() at the other end. It might happen to work when you
> do one thing at a time on localhost, but it won't be reliable on the
> internet or when there's more traffic. So you'll need to delimit
> messages; I recommend you use one of two classic ways: either prefix
> it with a length (so you know how many more bytes to receive), or
> terminate it with a newline (which depends on there not being a
> newline in the text).

Completely agree, and I'll point out
http://stromberg.dnsalias.org/~dstromberg/bufsock.html , which makes
it a little easier to deal with delimiters like newlines or null
termination.

> Another rather important point, in two halves. You're writing this for
> Python 2, and you're writing with no Unicode handling. I strongly
> recommend that you switch to Python 3 and support full Unicode.

Agreed.  It's time modernize.  Don't leave out people on the other
side of the world for no reason other than a modicum of convenience
for the developer.

> Using Python 3.4 (which isn't yet
> stable, but you can download betas) also gives you an asyncio module,
> but I'd leave that aside for the moment; first figure out threading,
> it's likely to be easier.

Personally, I don't like asynchronous I/O, EG twisted.  It tends to
give very complex, uniprocessor solutions to problems, even when those
problems have quite simple, alternative solutions.  I'd rather just
accept and fork in most cases, with or without multiprocessing.



More information about the Python-list mailing list