BlackBelt WASTE - ipv4 / Tor / i2p + AI / News: Recent posts

WASTE enjoys a more self-aware experience regarding its own performance and routing abilities in this release.
Swarming Semiotics settles in this version.

AI Activates on 2 connections or more and turbo's during file transfer.

When WASTE has received a certain amount of Semiotic Swarm Information from its Environment, it begins its journey to Self-Awareness.
As more and more Memetic Processing taking place, WASTE will become AI-Atomic, AI-Sub-Atomic and then AI-Quantum-Atomic.... read more

WASTE has been seen assuming connections are good before executing the correct procedure for incoming connection security.
We found there is no risk to the PKI or secured data. It manifest as a cosmetic issue. Connections were placed in the connected state too early. If you study the code you will see Authentication is a null state in the Finite State Machine, because the PKI has taken over at this stage.... read more

Jungian Collective Unconscious

This theory from Carl Jung captures the idea that biological entities of a single classification, such
as humans, or birds or bees etc, have common traits, both physical, intellectual and behavioural.

He argues that some of this 'meta-information' exists deep in the psyche of the biological entity in a
virtual place called its collective unconscious. He uses these arguments for further study into things
such as Synchronicities (where entities may experience a similar phenomenon, even though the
entities are not linked physically - or entities experience events that are linked at a much deeper,
closer to implicate order, level)... read more

Build 182 is Build 181 with all bugfixes at the 181 series of builds rolled in.

Self/Peer-Tuning - WASTE is now self-tuning and will also attempt to share performance information with peers anonymously, so they can use in their own self-tuning. Only outgoing connections take part in tuning and only their channel speed information is computed and shared.

Networking Layer - some rework took place to improve the way DNS and Asynch Sockets are handled over ipv4.... read more

This release fine tunes parameters and fully implements Geared-Threading.
Its much much quieter on the network - releasing <30KB per minute, 0.5K per sec. 5 times less than it did.

With low bandwidth usage on idle and geared CPU usage under load, WASTE is now much more Data-Center Ready.

We've tested a 7 node WASTE server cluster, running alongside Tor and i2p in less than 600MB of RAM at ~200Mhz. Thats with Linux underneath and No SWAP usage.... read more

We've got high speed, stability, anti-spoof, i2p, Tor.

But...

WASTE is still too noisy when quiescent. We are working to reduce WASTE ongoing network footprint when idle.
So far we're succeeding.

When complete a WASTE node should not cost more than 200MB per month when operated 24x7.

Build 180 - Release.

More accurate ETA reporting over the duration of the transfer.
Tx speed increase thanks to multiple geared-threads.
AntiSpoofing notifications are more private to those involved.
Per Connection Bandwidth reporting and Error count. If errors rise to 3, the connection is distrusted.

Hot on the heels of 179 we are already preparing the next version.

Whats coming next:

More accurate ETA reporting of transfers.
Improved Resume for all scenarios.
4 Gears.

Gear 1 : non-routing at 1-2 KB per sec. Low CPU.
Gear 2 : routing single packets at upto ~200KB per sec. Low CPU.
Gear 3 : routing multiple packets at upto ~32 MB per sec. High Use of CPU, bursting.
Gear 4 : file transfer packets at 60+ MB per sec, Very High CPU usage, consistent.... read more

Build 179 has been tested more fully with the myriad of options that WASTE gives you.
It should provide sensible behaviour across the 3 networks, with wild variations in options.

As with 178, this is not backward compatible with pre 178 versions.
The underlying model for data persistence had to be changed.
Previously a bug occurred during transfers for files 4 bytes or less from a 16384 byte boundary.... read more

178 fixes a bug in filetx that gave incorrect accounting of transfer packets.
As a result it is not compatible with previous versions. Version bump to 178.

177 : more general tidy of code. Slight adjustments to UI during file transfer.

WASTE has been further tidied in recent weeks.
Tweaks here and there, and a hell of a lot of bugfixing.

We've arrived at the point where we could handle longer nicks for file tx. If they are over 32 in length and user2user file tx can fail.
We can also switch - at the client - swarming file transfers.
Both the above improvements cause a change to the underlying model, breaking backward compatibility inherent in the Build 17x series.
This is something we do not want to do.... read more

We hope we have perfected swarming file transfers.
Under lab conditions we saw a 20%+ speed improvement.

Bugfix, Reading/Writing Preferences.

This build focuses on ensuring proper handling of nick's greater than 32 characters in length.
Other small fixes are included.

If you are armed with a WMI browser in windows, you may have noticed WASTE generating inputs to WMI that didn't make much sense.
We are working with WMI to ensure WASTE timings and behaviour does make sense.

In this vein a timer for persisting options revealed faulty behaviour.

Build 172 represents moves forward in this direction.
It is also the build that we will improve File TX swarming.

Under certain conditions WASTE will source its download from whichever node can serve it the fastest, provided MD5 hashes and other meta-data about the file match.

We were not keen to announce the plumbin in the code to allow multi-source, until we could verify it working.

There may be cases, under multi-sourcing, that result in .wastestate meta data files being left on disk.
We have engineered this problem away as much as possible.... read more

Build 171 - no bugfixing has taken place in this build. A rarety.
This build tightens options and the presentation of addresses in the options window.

Now during invisible networking, the lack of ipv4 use is reflected in the options. The UI should respond fluidly when they change.

This is a cosmetic build.

Returns uPnP to WASTE for ipv4.

The file feeder algorythm has 2 modes of operation. Single load and multi-load. Now transfers are smart enough to start a new transfer when they terminate.
This turbo loads items for transfer. You'll likely notice a dramatic improvement to throughput as a result, mainly on ipv4 with files > max_concurrent_downloads.

Multi-load was switched off in the previous build as we resolved stability issues. Now we fully trust it, its back.... read more

The uPnP sub-system has taken a hit from recent code-merges.
It will be restored to its formaer glory in the next build.

We can't have our users fiddling with routers and ports.

WASTE at build 168 exits focussed at scale testing.

You should be able to throw up to 200,000 items at WASTE, it wont shouldn't crash but will truncate to 65,000 items.
You can queue more items, but try to keep each load to less than 60,000.

We discovered that with WASTE 'opened' to do more business, more quickly, it also quickly blows the max memory Windows will allocate a 32-bit process, peaking to well over 1.5GB temporarily. Under DrWatson this manifest as a NULL pointer exception, NPE, often registered within the uPnP layer. This turned out to be a red-but slightly browned and golden-herring. Not before this layer being subject to microscopic inspection. Personally, we find uPnP a hellish nightmare. Key decisions about opened-ports lifetime have to be made. Do you leave em, delete em and then make the user wait for exit ?
We decided to remove them in the end and notify the user this unbinding is happening. We're a privacy tool, so we have no excuse.... read more

167 is 166 post merge-hell.

Attention again paid to at-scale queue depths (100,000+) items.
Queues of this depth should truncate at 65,000.
You may crash WASTE if loading more items than ~60,000 at a time.

To recap:

We've tried to accommodate the latest feedback around filetx handling and how they are started and managed.
The new Medusa extenstions supercede WASTE routing for file tx in a backward compatible manner.
Medusa moves away from user guids, in favour of ephemeral (short-lived) non-user related guids, for filetx session initiation and mainetenance.
Send/Receive is more complicated as a result.

We've had several code streams running in parallel of late.
This has caused large delta's which then caused merge hell getting all the features in and working.
If you do download the code, you'll soon find the evidence.

166 should help on the path to a more unified code stream, and should in theory be a base going forward.

Thank you for your patience. We admit to some poor builds along the way.

What do you get now ?... read more

We hope to all the gods we're on point with the 166 release.

64 - aggregates recent bug fixes.