Title: Morphtek.com Inc. Announces the Release of Open Source Peer to Peer Component Suite
Question: News Release
Answer:
Peer to Peer Intelligent Communication Components
There are many Peer to Peer technologies on the market today but what these technologies provide is not a great deal of innovation. File Exhange protocols appear to be the main Peer to Peer implementation since this is probably the simplest form of Peer to Peer technology. But what about protocols that enable the sharing of ideas and concepts? What about distributed database protocols or distributed computing protocols? What about protocols that handle instant messages? Most of these protocols are very proprietary and hence the full potential of peer to peer technology is not readily available to developers.
What if we had an open suite of components that encapsulated the basics of the Peer to Peer technology so that developers could concentrate on writing Peer to Peer protocols without needing to concern themselves with the low level coding requirements?
Morphtek.com Inc. has written such a component suite (see http://www.morphtek.com/opensrc.html) and is offering it open source. It encapsulates a protocol manager that can handle multiple protocol components of a custom protocol class. This custom class is intended to be inherited for each specific protocol. Messages are therefore managed by the protocol manager and passed to the indicated protocol which then handles attached information.
The concept is very simple, yet it is extremely powerful in it's application. By simply placing a Peer to Peer manager onto a form and attaching several customized protocol components to it, a stand-alone application immediately joins a peer network with abilities that previously needed to be coded within the application.
The only drawback of this approach is the need to prefix each message with a generic header. This header is defined in two parts;
// This is the Main Protocol Header -
// All messages use this to identify the protocol that is to
// manage the attached message.
PMtkPPPHeader = ^TMtkPPPHeader;
TMtkPPPHeader = packed record
ProtocolID : Word; // I.E. 65536 possible protocols
MessageTyp : TMtkMsgType;
IPAddress : Integer; // The IP Address of the
// Requestor/Responder
end;
// This is the Custom PPP Protocol Message Header.
// All messages have this secondary header that is handled by
// the Custom Protocol Object.
// It identifies a unique message, who created it, the function
// that is to be executed,
// how long it has to live, how many times it was passed on and
// the length of the attached message data.
PMtkMsgHeader = ^TMtkMsgHeader;
TMtkMsgHeader = packed record
MsgID : TGUID; // A Globally Unique
// Message Identifier
MsgCreator : TGUID; // A Globally Unique
// Identifier of the
// message Creator
FunctionCode : Byte; // The Function of this
// message
TTLRemaining : Byte; // Time to Live Indicator
JumpsTaken : Byte; // How many times this
// message was passed on
DataLength : Integer; // The length of the
// attached data
end;
After the message header, a message specific to the target protocol usually follows. Because the message header identifies the protocol that is to handle the message, identical function codes in the message header may be handled differently by the target protocols.
Another innovation introduced with these components is that a socket connection only remains active for as long as it is needed. That is; once a message is sent, the connection is closed. This therefore eliminates the need to code for what to do if a connection is lost since the components described here are not dependent on a live connection. Rather they establish connections as required and communicate though such connections in one direction only. That is, a request is sent to those known peers that can be reached and responses are sent back along the path that they were received on.
In effect, the communication is somewhat like an internet protocol - but instead of a client sending a request to a server, that request is sent to known participants in the network and responses are routed back to the requestor via participating peers. Since there is no server at all, the network can not easily be described - Morphtek is working on various innovative solutions that we will encapsulate network topological intelligence into the base components so that a client computer can join the network and leave the network at will, yet receive messages addressed to it that were previously not received. Broken links in peer chains will likewise be adressed by this encapsulated intelligence so that broken links will be repaired transparently.
Since Morphtek invites developers to participate in the open source development, I encourage developers to write to them and join the open peer to peer development effort.