There's an old joke. It was said that English automobiles of the 1950's came equipped with a walnut inlayed toolbox containing many hammers. These ranged in size from a small jeweler's hammer up through a heavy, concrete shattering, sledge. It was said that when something in the automobile stopped working that one should begin by pounding on it with the smallest hammer. If that didn't solve the problem then one should move up to the next larger size. And so on, using ever larger hammers, until the sledge, which would reduce the automobile to a heap of shattered parts that could easily be hauled away – because the original problem was obviously insolvable.
Fuzz testing of software is somewhat like that old English automotive technique, but often without the benefit of an orderly sequence.
The question of “how many bits” were sent and received clearly is a matter of interest when measuring data rates or data quantities.
Mobile providers, consumer ISP's, consumers, and regulators talk a lot about their speed and (not so often) about their data caps. But rarely, if ever, are sufficient details provided:
And it is not just a consumer issue: ISPs that exchange data with one another under contractual peering and transit arrangements need common ground when they discuss how much data each party is delivering to the other.
Despite what one might read in certain techno-marketing publications, IPv4 is very much alive; it has not by any stretch yet been replaced by IPv6.
So it remains important that vendors of networking products do IPv4 and do it correctly.
But some vendors appear to be getting lazy.
In particular one of the largest vendors seems to be taking a shortcut that could leave users unable to communicate even though those users have otherwise perfectly usable packet service from their network providers.
Have you thought about how you will test the performance of IoT apps and drones? Our new video demonstrates performance testing of an IOT application controlling the ESP8266 Microcomputer mounted on a drone! As you might expect, as the drone flies further away from the wireless base station, perform...
Real network conditions are rarely static. Real life networks suffer transient conditions – congestion builds up and dissipates, tree branches wave in the wind across radio links, long distance routing paths change, VoIP call trunks are filled with more calls during working hours than during the evening. Even something as small as a person standing near a wi-fi access point can change the carrying capacity of a network.