Re: Five Reasons Why Synchronous Networking Is Bad
Re: Five Reasons Why Synchronous Networking Is Bad
- Subject: Re: Five Reasons Why Synchronous Networking Is Bad
- From: email@hidden
- Date: Thu, 05 Mar 2009 20:39:34 -0700
On Mar 5, 2009, at 9:51 AM, Jens Alfke wrote:
On Mar 5, 2009, at 8:20 AM, email@hidden wrote:
Just thought that I'd throw something else out there: traditional
networking education has been disastrous for programming large
scale projects. For example, notice that nearly all web browsers
still block and spin the beachball while loading a page.
Um, no, this is not true, and I can't think of any real web browser
it's ever been true for. (Even NCSA Mosaic stayed responsive while
it was loading a page, and demonstrated this via the 'throbber'
animation.) In particular, every browser since Netscape 0.9 has
loaded multiple resources in parallel, to speed up page loads, which
you obviously can't do using simple-minded single-threaded blocking
I/O.
I'm drawing a blank thinking of modern non-browser apps that
beachball while reading from the network...
It's possible that something may occur while loading a page that
takes an unexpectedly long time on the main thread and causes a
brief beachball. This is possible if the system is under memory
pressure and has to page stuff in. In the Safari app there is also
some file I/O that takes place on the main thread, including
periodic web-cache cleanups, that I've seen beachball if the disk is
very busy. But none of that has to do with networking.
Just wanted to clarify what I meant here so I don't sound clueless
hah. I'm sure that an app like Safari has separate threads for every
tab and never blocks on the network etc etc, but the real world result
is that any browser I've ever used beachballs constantly as soon as I
have more than a handful of tabs open, and often even on a single
tab. It might be a filesystem call to load a picture or something
reading virtual memory, I don't really know. Contrast that with
Google's Chrome that from what I understand has a separate process for
each tab, or at least a process per server I believe. The parent
process should be able to manage the child processes without ever
beachballing. I actually had the idea 5 years ago to make a Safari
clone with a process in each tab running WebKit, but realized there
would just be no money in it and I'd lose myself in a project like
that, not to mention I'd probably screw it up haha. Anyway I haven't
used Chrome much because the interface is still a bit lacking, but I
really think separate processes will be the future of browsers, and I
really hope Apple adopts it for Safari.
Today's apps can't have even a single bug or they are considered
unusable.
If only it were so … any shipping app has dozens of 'em. I've never
worked on a release of any project that didn't ship with significant
numbers of known bugs, and didn't have further bug reports come in
later. (Who was it that said that any program longer than 100 lines
contains bugs? (Unless it's TeX, of course. But we can't all be
Knuth.))
Here I just meant that networking has a separate class of bugs that
people don't tolerate. Like, in our games, we have a bug where the
screen gets garbled and we get an email every few days where we have
to tell people "set the graphics mode to more compatible" and they are
happy with that. They don't care that it's a serious bug if there is
a foolproof workaround. Meanwhile I had bugs in our chat system when
the game would hang during startup waiting on events from two
different event sources, maybe 5% of the time. People don't tolerate
that, they say the app is hopelessly broken and don't even see the
level of work put into the rest of the game, no matter how shiny it
is. I have yet to solve the networking problems in our games because
frankly dealing with the possible permutations of 2 or more event
sources could be one or two full semesters of college. I think the
jury's still out on how to do it properly honestly.
I'm looking at another full rewrite, but I spent several days a while
back studying Erlang and I THINK the secret is pattern matching.
Basically you make lists of patterns from event sources like A,C,B
that trigger changes of state. It's tolerant to hacking attempts
because it's like dialing a phone, only the proper combination
achieves the desired effect, and weeds out garbage events. Also
timeouts and errors can be considered additional inputs to the
pattern. It could become a wild goose chase of accepting A,B or B,A,
but it should be a much smaller problem space than making wait loops
with complicated conditions and subloops to handle unexpected
exceptions. I've been down that path and found myself thinking "this
can't possibly be the answer" hahah. I have a newfound respect for
the people who wrote Adium and Skype because they got file sending and
even audio/video working over multiple protocols and through NAT which
is no small achievement.
I also wish we had a construct for in-process processes. In other
words, we need threads that don't have global variables, so that
all state is passed through messages.
That is exactly the Actor model. It's also very much like Grand
Central Dispatch, the new concurrency system coming in OS X 10.6.
Sounds great, can't wait to see it! Also it's good to hear your
thoughts on Scala etc, I personally think that networking is one of
the hardest subjects in computer science (far harder than...gasp...3D
rendering) and I would really like to see a semester course on
concurrency required early on to get a CS degree, because it would put
students on the path to being open to these concepts, although maybe
things have changed since I was in school in the 90's. I only
personally know a handful of programmers who have come up against
these challenges, but one glimmer of hope is that web programmers
don't generally understand them and don't usually have to worry about
them, and their applications are incredibly rich and bulletproof,
handling hundreds or thousands of simultaneous users. They can rely
on a MySQL database and sandboxed php script to do most of the heavy
lifting. I think that signals that transaction-based concurrency is
probably the future of multi-core programming. I know that I can get
it all to work without touching preemptive threads (or also by using
the process-in-process concept), and honestly those may be the only
ways for me to safely and reliably do it, once the complexity passes a
certain point. I really would like to know the end-all, be-all
solution of networking, but maybe it's something that doesn't exist or
is different for each person, like the secret of life or whatever
hahah :-) Having a simple game lounge and puzzle game that doesn't
hang every 5 minutes would sure do wonders for my psyche though.
--Zack
"We are all failures -- at least, all the best of us are."
--Sir James M. Barrie, British Playwright _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden