September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



Networks

  Download PDF version of this article PDF

Error 526 Ray ID: 47b981ce8dc921a4 • 2018-11-18 09:45:56 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 7, no. 3
see this item in the ACM Digital Library


Tweet


Related:

Yonatan Sompolinsky, Aviv Zohar - Bitcoin's Underlying Incentives
The unseen economic forces that govern the Bitcoin protocol


Antony Alappatt - Network Applications Are Interactive
The network era requires new models, with interactions instead of algorithms.


Jacob Loveless - Cache Me If You Can
Building a decentralized web-delivery model


Theo Schlossnagle - Time, but Faster
A computing adventure about time through the looking glass



Comments

(newest first)

Craig Everett | Mon, 07 Apr 2014 12:02:02 UTC

Excellent article.

The basic rule seems to be that when a separate, intermediate node on the network would be a useful place to offload a task then an NFE makes sense. Whenever that is not the case, the overhead is higher than the payoff so streamlining within the system is the better option. In that context Julian's comment describes an in-place optimization, not a new class of solutions (that software isn't properly taking advantage of multiple cores is the OS's fault; this is an article about hardware design).

I think this issue is really much more broad than hardware interfaces, though. To me it is about process encapsulation and how tasks relate to messages. The difficulty of implementing an NFE in a beneficial way is a symptom of conceptual violation of some basic rules.

Going even farther, I think the time will come when each process carries its basic data along with it -- sort of a mobile closure (I'm sure there is a better word for this, but Alan Kay's term "object" has already been hijacked). Each of these closed bundles will provide themselves with their own basic I/O facilities, and we won't focus so much on where the execution actually happens. We do this to great effect today in, say, the Erlang runtime. Hardware support, not software runtime implementation, for this sort of thing would likely render a lot of the performance concerns we have today moot, and drastically shrink the necessary exposed surface of an OS. That this makes the most sense as a hardware reaction to software is probably what the reconfigurable computing guys were originally getting at.

Of course, none of this would spell a happy future for the "capture everyone's bits so we can sell them back to the user" cloud model, so it won't catch on anytime soon.


Julian Satran | Sun, 26 Dec 2010 06:55:55 UTC

Mike - good overview. However I wonder why you are ignoring a new class of solutions that are a good match for current multicores - dedicating cores for I/O function. I and several colleagues have experimented and published both architectures as well as experimental results (including a protocol stack that is 4-6times "better" than general purpose stack. Those solutions might involve in the long run some (new) hardware but are readily usable now without any additional hardware. And Intel has published similar results (limited to the TCP/IP stack) - and they call this technology "onloading".

Thanks


Nick Black | Sat, 27 Jun 2009 15:09:44 UTC

That was outstanding! Thanks, Mike!


Simon Kenyon | Wed, 13 May 2009 15:19:54 UTC

insightful as always


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.