Archive

Category Archives for "Networking"

BGPsec and Reality

From time to time, someone publishes a new blog post lauding the wonderfulness of BGPsec, such as this one over at the Internet Society. In return, I sometimes feel like I am a broken record discussing the problems with the basic idea of BGPsec—while it can solve some problems, it creates a lot of new ones. Overall, BGPsec, as defined by the IETF Secure Interdomain (SIDR) working group is a “bad idea,” a classic study in the power of unintended consequences, and the fond hope that more processing power can solve everything. To begin, a quick review of the operation of BGPsec might be in order. Essentially, each AS in the AS Path signs the “BGP update” as it passes through the internetwork, as shown below.

In this diagram, assume AS65000 is originating some route at A, and advertising it to AS65001 and AS65002 at B and C. At B, the route is advertised with a cryptographic signature “covering” the first two hops in the AS Path, AS65000 and AS65001. At C, the route is advertised with a cryptogrphic signature “covering” the first two hops in the AS Path, AS65000 and AS65002. When F advertises this route to H, at Continue reading

History of computers, part 2 — TCP/IP owes a lot to Xerox PUP

To understand where we are going, we first must understand where we have been. This applies equally well to the history of nations across the globe as it does to computers and computer networking.With that in mind, we’re taking a slow (somewhat meandering) stroll through the history of how computers talk to each other. Last time, we talked a bit about dial-up Bulletin Board Systems (BBSs) – popular through the 1980s and the bulk of the 1990s.Also on Network World: The hidden cause of slow Internet and how to fix it Today, I’d like to talk about one of the most influential, but rarely discussed, networking protocol suites: PARC Universal Packet (PUP).To read this article in full or to leave a comment, please click here

History of computers, part 2 — TCP/IP owes a lot to Xerox PUP

To understand where we are going, we first must understand where we have been. This applies equally well to the history of nations across the globe as it does to computers and computer networking.With that in mind, we’re taking a slow (somewhat meandering) stroll through the history of how computers talk to each other. Last time, we talked a bit about dial-up Bulletin Board Systems (BBSs) – popular through the 1980s and the bulk of the 1990s.Also on Network World: The hidden cause of slow Internet and how to fix it Today, I’d like to talk about one of the most influential, but rarely discussed, networking protocol suites: PARC Universal Packet (PUP).To read this article in full or to leave a comment, please click here

IBM casts Watson as the brains behind IoT

IBM is trying to be the brains behind the increasingly brawny presence of IoT in all corners of the business world, using its AI expertise to offer insight into piles of new data, provision new implementations, and help drive decision-making.The company thinks that its Watson AI is the ideal back-end for IoT, which is an area that few companies are addressing so directly. There’s a great deal of uptake around technology that connects new devices to the network, but comparatively little that actually does meaningful work on the floods of new data provided as a consequence.+ALSO ON NETWORK WORLD: REVIEW: Turbonomic, VMware virtualization management tools + Cisco snaps up streaming-data startup PerspicaTo read this article in full or to leave a comment, please click here

Worth Reading: The Economics of DDoS

These days, there are typically three parties to a distributed denial of service attack. You probably know about two of them: the perpetrator and the target. Less well known is the vast and growing number of third-party providers of DDoS attacks as a service. Brazenly advertising their wares online, these providers will perform an attack on the customer’s behalf and provide detailed reports of their accomplishments. Their fees are shrinking due to rapidly expanding competition and the abundant supply of readily available attack resources, such as botnets. As a result, the DDoS attack business is very much a buyer’s market. —Kevin Whalen @Arbor

The post Worth Reading: The Economics of DDoS appeared first on rule 11 reader.

Why network operations should care about AppDynamics

Earlier this year, Cisco surprised many industry watchers when it forked out a cool $3.7 billion to acquire AppDynamics, which was about 2x the valuation it had going into its IPO. Most people know Cisco as the de facto standard and market leader in networking. AppDynamics lives higher up the stack and provides a view into how applications are performing by collecting data from users, applications, databases and servers.One might surmise that Cisco will use AppDynamics to go after a different buyer, and that assumption is correct. AppDynamics paves the way for Cisco to have a meaningful discussion with lines of business, application developers and company leaders. However, thinking AppDynamics isn’t for Cisco’s current core customers, network engineers, is wrong. AppDynamics can provide an equal amount of value to that audience.To read this article in full or to leave a comment, please click here

Why network operations should care about AppDynamics

Earlier this year, Cisco surprised many industry watchers when it forked out a cool $3.7 billion to acquire AppDynamics, which was about 2x the valuation it had going into its IPO. Most people know Cisco as the de facto standard and market leader in networking. AppDynamics lives higher up the stack and provides a view into how applications are performing by collecting data from users, applications, databases and servers.One might surmise that Cisco will use AppDynamics to go after a different buyer, and that assumption is correct. AppDynamics paves the way for Cisco to have a meaningful discussion with lines of business, application developers and company leaders. However, thinking AppDynamics isn’t for Cisco’s current core customers, network engineers, is wrong. AppDynamics can provide an equal amount of value to that audience.To read this article in full or to leave a comment, please click here

Today, $50 off Sennheiser’s HD1 In-Ear Wireless Headphones – Deal Alert

The HD1 In-Ear Wireless headphones from industry veteran Sennheiser combines immaculate sound quality with take-anywhere mobility. Utilizing a sleek ergonomic design and crafted with high-quality materials, this premium headset exudes luxury. Exceptional wireless hi-fi sound is assured thanks to Bluetooth 4.1 with ACC and Qualcomm apt-X technologies. Featuring NFC for simple one touch pairing, an integrated microphone and ten-hour battery life, the HD1 In-Ear Wireless is a perfect companion to mobile devices. The typical list price of the HD1's is discounted 25% for today only, so you can get them for $149.95. See this deal now on Amazon.To read this article in full or to leave a comment, please click here

Why does one NGINX worker take all the load?

Why does one NGINX worker take all the load?

Scaling up TCP servers is usually straightforward. Most deployments start by using a single process setup. When the need arises more worker processes are added. This is a scalability model for many applications, including HTTP servers like Apache, NGINX or Lighttpd.

Why does one NGINX worker take all the load?CC BY-SA 2.0 image by Paul Townsend

Increasing the number of worker processes is a great way to overcome a single CPU core bottleneck, but opens a whole new set of problems.

There are generally three ways of designing a TCP server with regard to performance:

(a) Single listen socket, single worker process.

(b) Single listen socket, multiple worker processes.

(c) Multiple worker processes, each with separate listen socket.

Why does one NGINX worker take all the load?

(a) Single listen socket, single worker process This is the simplest model, where processing is limited to a single CPU. A single worker process is doing both accept() calls to receive the new connections and processing of the requests themselves. This model is the preferred Lighttpd setup.

Why does one NGINX worker take all the load?

(b) Single listen socket, multiple worker process The new connections sit in a single kernel data structure (the listen socket). Multiple worker processes are doing both the accept() calls and processing of the requests. This model enables some spreading of the inbound Continue reading

1 … 1,616 1,617 1,618 1,619 1,620 … 3,480