Visit developers section
Some time ago we’ve been facing a stunning launch of
a revolutionary technology called “Peer-to-Peer”.
There is no need to specifically notice that this technology
paved the way for the next step for the data sharing industry,
allowing many people to share the resources in the nearly
easiest way possible.
Despite all the bells and whistles the modern
P2P systems now have, there is always one question to ask
– what kind of resources do they allow for share? Music
– this was the first bird on the new breath, then the
scope has broadened to files, or in some cases narrowed down
to pictures only. But now let’s just think of one simple
fact – each P2P network that comes into play, has its
own name, its own bells and whistles, and most important,
it does have its own network. So when users which are using
P2P network “A” for sharing e.g. music notice
a P2P network “B” which allows sharing e.g. pictures,
they need to join this new network too, keeping 2 client side
programs on the PC, and having to wait until this network
“B” gains enough userbase to become usable in
its direct purpose – to provide a searchable database
of certain resources. Then if a P2P network “C”,
which allows sharing e.g. game character files gets launched,
the whole process of “install-wait_until_grown-use”
is happening back again.
Now we can imagine there is ONE P2P network
which can share any kind of resources. It utilizes a certain
client software, which supports plugins – the plugins
are to be responsible for actual sharing the resources. This
means that once the client software is installed on all PCs,
it only takes to develop a plugin to make the huge network
being able to provide circulation of the new resource. The
core idea is that each plugin is responsible for sharing one
single kind of resource.
Why developing a plugin instead of a new application?
Here is why:
- Each new plugin released for that network is immediately
settled on the whole userbase, and is able to utilize all
the P2P network power gained to date.
- Programmer doesn’t need to care about network related
function calls, interfacing to other peers etc. Main program
provides a number of API calls for plugin to use. To request
another peer for sharing a resource, plugin asks main program
to contact a certain peer. Main program performs all the
tasks necessary to reach the target peer – then target
peer’s main program routes the request to the plugin
of the same kind. So plugins are communicating through the
means of the main program API calls, having no need to hassle
about direct network communication.
- There can also be network-passive plugins, which don’t
necessarily share resources. Several plugins installed on
the same peer can communicate with each other too. E.g.
a chat plugin which allows users to exchange text messages,
can utilize a network-passive plugin that offers PGP encryption.
Or, file exchange plugin can make use of a network-passive
MP3 compression plugin, to compress music files before sending
them, or use a anti-virus checking plugin to check every
incoming file for viruses. Even more – a file exchange
plugin can also make use of the chat plugin, which is not
network-passive (as it shares a certain resource), to allow
users to chat before/after exchanging files. Possibilities
are endless and are only limited by the fantasy of the developers.
- Distributing a plugin is much easier than distributing
a whole application – at least in terms of file size.
An average plugin can be 300 to 500 Kb, while most P2P client
program installations usually weigh several megabytes, and
every new beta release urges users to download the new version
fully. In case of plugins, each plugin author decides when
to release a new version of the plugin – so the application
is updated when user wants, and how user wants.
- Finally, this approach is much more alike the way Internet
was developing itself. The current state of P2P applications
looks more like tens of different incompatible Ethernet
flavours hanging around – with this situation in place,
Internet would never appear at all, since it would never
be possible to connect networks which are using different
standards. But once TCP/IP and Ethernet have become industry
standards, it was a matter of time to connect all subnetworks
into one big network we now know as Internet. I think using
this approach in terms of P2P networking would allow to
unite the resource sharing tasks around the globe.
We truly believe Arkamatrix ideas are worth thinking and
implementing. And I welcome everybody who is interested in
modern communications technologies to join us in this unbelievably
wonderful research.
Artyom Kamshilin a.k.a. "arkamax" and Arkamatrix
team
|
