Learning python networking

[Chris Angelico]

On Thu, Jan 9, 2014 at 10:53 AM, Dan Stromberg <drsalists at gmail.com> wrote:
>> 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.

I haven't used the Python asyncio module yet (haven't gotten around to
it, no other reason), but in my Pike work, I've gotten quite friendly
with a callback system. It plays nicely with the structure I have for
code reloading, by separating code and data, and then simply running
everything off a single thread, one callback at a time. Works really
well when everything's waiting anyway. It does force you to think
about things differently, though. Case in point: My MUD client allows
an arbitrary number of code files to inspect a line of text that the
user's entered, before it goes to the server. Any one of them can
suppress the line, in which case subsequent hooks won't see it and it
won't go to the server. What about changing the line as it goes
through? That's easy enough, I guess. But what if that change involves
a popup message and user response... or a network request to a remote
server? (I do, in fact, have exactly that. Long URLs get shortened via
tinyurl.com.) A threaded model wouldn't even help much, here, unless
I'm prepared to spawn a separate thread for every command the user
enters, which is stupid overhead. Instead, I have a function that
reinjects the line and carries on as if it hadn't been suppressed in
the first place.

Maybe it's not the best way to do things, but it can be extremely
simple in the code. Most operations don't even need the
continuation-call mechanism that I used there; mostly, everything's
just (conceptually) "when this happens, call this function". The fact
that they're serialized doesn't matter. Events from the GUI, incoming
socket data (on any socket - there might be multiple), time-delay
events (eg a ticking clock), etc - everything works the same way. It's
really easy once you get your head around it.

ChrisA