Communications protocol
From Wikipedia, the free encyclopedia
(Redirected from Protocol (computing))
For other uses, see Protocol (disambiguation).
In telecommunications, a communication protocol is a system of rules that allow that two or more entities of acommunication system to communicate between them to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.[1]
Communicating systems use well-defined formats (protocol) for exchanging messages. Each message has an exact meaning intended to elicit a response from a range of possible responses pre-determined for that particular situation. The specified behavior is typically independent of how it is to be implemented. Communication protocols have to be agreed upon by the parties involved.[2] To reach agreement, a protocol may be developed into a technical standard. Aprogramming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communications as programming languages are to computations.[3]
List of P2P protocols
From Wikipedia, the free encyclopedia
Contents
[hide]
1 Protocols used by multiple programs
2 Protocols used by only one program
3 Programs not also listed as protocols
4 See also
Protocols used by multiple programs[edit]
Note that the name of the protocol may also be the name of the primary or original program that uses it.
Ares (Ares Galaxy, Warez P2P)
Bitcoin (Bitcoin, Alt-Coins)
BitTorrent (ABC (Yet Another BitTorrent Client), BitComet, BitSpirit, BitTornado, BitTorrent.Net, G3 Torrent, mlMac, MLdonkey, QTorrent, Shareaza, Tribler, µTorrent, Vuze (previously Azureus) etc.)
Direct Connect (BCDC++, DC++, NeoModus Direct Connect, etc.)
FastTrack (Grokster, iMesh, Kazaa, Morpheus, etc.)
eDonkey (eMule, Overnet, etc.)
Gnutella (BearShare, iMesh, Gnotella, Gnucleus, GTK-gnutella, LimeWire, Frostwire, Mactella, Shareaza, etc.)
MANOLITO/MP2PN (Blubster, Piolet, RocketItNet)
OpenNap (Napigator, WinMX)
RShare (RShare software, StealthNet)
Protocols used by only one program[edit]
100Bao
Aimster
Applejuice
Filetopia
Freenet
GnucleusLAN (a variant of Gnucleus)
Goalbit
GoBoogy
Infinit
KuGoo
OpenFT (giFT)
MUTE
RetroShare
Soribada
Soulseek
Xunlei
Programs not also listed as protocols[edit]
This section may be confusing or unclear to readers. (March 2015)
BearShare: Gnutella
Blubster: MP2PN
Gnotella: Gnutella
Gnucleus: Gnutella
Grokster: FastTrack
GTK-gnutella: Gnutella
iMesh: Gnutella, FastTrack
Kazaa: FastTrack
Limewire: Gnutella
Mactella: Gnutella
MXIE: BitTorrent, eDonkey, (?)
Morpheus: FastTrack
Piolet: MP2PN
RocketItNet: MP2PN
Shareaza: Gnutella, eDonkey, BitTorrent, HTTP, FTP
WinMX: OpenNap, WPNP
Vagaa: eDonkey, BitTorrent, (?)
See also[edit]
Open Peer
1.Abstract
The holy grail of communication on the Internet has been to allow peer-to-peer communication without the requirement of any centralized servers or services.A peer-to-peer approach offers some key advantages over a centralized server approach:
Greater network resilience - peers can continue to function independent of servers and can operate even if servers are down
Increased privacy and security - peers communicate directly thus the data is not centralized in one location where it can be spied upon by corporations, governments, 3rd parties or hackers.
Decreased cost - without the need of servers, the cost to host, administer, store and relay data is reduced substantially
Scalability - a peer to peer network doesn't require servers to scale as the peers can operate amongst themselves
Unfortunately, the goal of peer-to-peer and the reality of peer-to-peer do not match. Centralization of data into the Internet cloud is prolific and firewalls frequently impede direct peer-to-peer communication making peer-to-peer connection extremely difficult to setup and challenging to architect.
What further reduces the proliferation of peer-to-peer is a lack of standardization, openness and ubiquity of the technology. The standards bodies have been working for years on firewall traversal techniques and standardization of the approaches and a new joint effort called WebRTC between the W3C and IETF on how browsers can directly communication between browsers to move media. This joint effort does not specify how signaling happens between peers so it's not a complete solutions on its own.
Performing peer-to-peer approach to signaling has been notoriously difficult for a variety of reasons:
Without a publicly addressable intermediate 'server' machine to initiate communication, two peers behind firewalls are never able to communicate with each other. Thus, a peer network almost always requires some sort of rendezvous and relay servers to initiate contact between peers behind firewalls (and firewalls tend to be used more frequently than not for end users).
Automatically promoting the few publicly addressable home machines into rendezvous and relay servers is not the best option. Average users tend to not want to have their home/work machines to be automatically promoted to rendezvous and relay servers since it consumes their bandwidth and costs them to relay traffic for others who "leech" off their bandwidth. This cost factor causes end users to intentionally shutdown protocols that promote end user machines into servers. Over time, the number of average users willing to have their machines operate as servers for the benefit of those leeching decreases relative to the number of those whom leech off those servers until the entire system collapses with a too great server/leech ratio. As an example, Skype's network collapsed for this very reason and they were forced to setup their own super nodes to handle the load.
Some peer-to-peer networks require ports to be opened on a firewall to operate. Where possible, peers will register themselves with UPnP to open the ports when the firewall automatically. Unfortunately, many firewalls lack the ability to automatically open ports or actively disallow this feature for fear that this opens the network to security holes. If opening ports automatically is not possible then users are required to open ports manually. Thus only the technically savvy can perform this task and such peer networks tend to be limited to those who are technically savvy. This is not a universal solution since it assumes too much technical ability and responsibility of the end user.
Many peer networks rely on mutual peers not behaving in an evil manner. Peers that do not act in an altruistic fashion can easily disrupt these networks. When all peers behave properly there is no problem with such a network; however, the moment an 'evil' node or cluster of 'evil' nodes is injected into the peer network, parts or all of the network can suffer fatal issues and security can be compromised.
Open Peer is peer-to-peer signaling protocol taking advantages of the IETF advances of firewall penetration techniques for moving media and adds a layer to performs the media signalling in a peer-to- peer fashion but does expect that a minimal requirement of rendezvous servers existing. Beyond the initial rendezvous to get past firewalls, the servers should drop out of the protocol flow and are no longer required.
Open Peer was designed with these main goals in mind:
Openness - a protocol is freely available for anyone to implement.
Greater network resilience - peers can continue to function and interoperate even if servers are down.
Increased privacy and security - peers communicate directly in a secure fashion designed to protect against network ease dropping, forged communication or spying by 3rd parties or being a convenient data mining target for hackers as the information does not flow through centralized servers.
Federation - the protocol makes it easy for users on one service to communicate with users on another independent service offering.
Identity protection - the ability of users to easily provide proof of their identity using existing social platforms while protecting these identities from spoofed by others.
Decreased cost - without the need to continuously relay signaling or media through centralized servers, the costs to host, administer, relay, replicate, process and store data on servers while providing 5 9s uptime is decreased.
webRTC enabling protocol - designed to be the engine that allows webRTC to function, supporting federation of independent websites and services, provide security and online identity protection and validation, and peer-to-peer signaling bypassing the need for heavy cloud based infrastructure.
Scalability - whether starting at 50 users or moving beyond 5,00,000 users, the protocol is designed to allow for easy scalability by removing the complexity of communications out of the servers.
2.Design Considerations
The Open Peer Protocol has several design considerations to address the realities of the Internet infrastructure while delivering the functionality required:
Must allow any peer to connect to any other peer (if authorized).
Must understand firewall principles and to offer an architecture which factors that firewalls are prevalent and within the natural scope of the architecture's basic design.
Must accept that it's not always desirable to have peer machines automatically promoted to rendezvous servers.
Must allow additional services to be layered onto of the architecture
Must enable peers to find each other using directory services.
Must enable secure peer-to-peer communication without penetration or monitoring by third parties.
Must allow peers to perform identity validations.
Must allow anonymous peers, i.e. similar to unlisted and non-guessable phone numbers.
Must allow for differing server rendezvous architectures, i.e. anywhere from peer-to-peer self-organized models to centralized network layouts are to be abstracted from the protocol.
Must not require end user signed certificates from a known authority chain for each peers on the network to establish secure communications.
Must not require end users or administrators to configure firewalls or open ports under normal circumstances.
3.Key Object Concepts
3.1.Identity
An Identity is the persona of a peer contact, be they the representation of a real person or representative entity (much like a corporation is a legal entity but not a real person). An Identity maps to a single Peer Contact although a Peer Contact can have multiple Identities.
3.2.Asserted Identity
An Asserted Identity is an identity that can be verified through an identity service as being the legal owner of the persona rather than a fraudulent representation. In other words, a validated asserted identity can be trusted that they are whom they claim to be. Different levels of identity assertion can be claimed for any given identity starting with no provable assertion at all and moving anywhere from weak to strong verification depending on the identity validation service types available.
3.3.Identity Lookup Server
A server that looks up and returns the Peer Contact associated with an Identity or a set of Identities and can return the public profile information for Peer Contacts.
3.4.Identity Signing Service
A service that provides the Asserted Identities for the various personas that are owned within a particular service offering.
3.5.Identity Provider
Any service offering that grants Identity personas, such as Facebook, LinkedIn, Twitter or other 3rd parties that offer their own Identities.
3.6.Peer Contact
A Peer Contact is the representation of a single point of contact on the Internet regardless of the personas represented by the peer contact. A peer contact can exist at zero or more Peer Locations at any given time.
3.7.Peer
A Peer is the single instance of a peer client application on the Internet, which registers a single Peer Contact in the Peer Domain at a particular Peer Location.
3.8.Peer Location
A Peer Location is the representation of where a peer is located. A Peer can only exist at a single location but the Peer Contact for the Peer can register at multiple Peer Locations.
3.9.Peer URI
A Universal Resource Identifier (URI) starting with "peer:" offering the ability to locate a specific peer resource, protocol and request type within a peer domain.
3.10.Peer Domain
A Peer is always connected to a Peer Domain and the domain is the organization responsible for managing the connected peers.
3.11.Peer Finder
A Peer Finder is a rendezvous server that keeps track of connected peers at their peer locations since they are connected in a dispersed fashion through a peer domain. A peer finder will utilize a database (typically distributed) to facilitation the introduction of peer communication on the same domain or across domains.
3.12.Bootstrapper
A Bootstrapper is the introductory server where peers first go to be introduced to one (or more) Peer Finders. Peers should attempt to connect to introduced Peer Finders in order to gain entry to the Peer Domain. Once a Peer is connected to a Bootstrapped Network, the Peer should no longer require communication back to the Bootstrapper unless access to previously introduced Peer Finders are no longer accessible.
3.13.Bootstrapped Network
A Bootstrapped Network is the representation of the entire peering network that was introduced from a Bootstrapper.
3.14.Public Peer File
A file that contains a cryptography public key for secure conversations, information required to locate the Peer Contact within a Peer Domain, information to authorize a connection to that Peer by another Peer and public Identities associated to a peer. Any Peer without the correct Public Peer File for another Peer Contact will be unable to connect to that peer. A directory service can host and offer these Public Peer Files between peers but without this file no communication is possible between peers (thus allowing for "unlisted" peers).
3.15.Private Peer File
A file that contains a private key to be the pair of a public key inside the Public Peer file that is used by a Peer to be used to establish secure communications between Peers. The Private Peer File is encrypted and can only be decoded with the correct key.
3.16.Peer Pair
A file pairing consisting of both a Public Peer File and a Private Peer File.
3.17.Provisioning Service
A service that provides account creation and account profile maintenance.
3.18.Peer Service
Any additional services offered to peers are done through what is called a Peer Service. Examples of such services are those that perform identity assertion, TURN or future services like video conferencing mixers.
wonderino
commented
9 years ago
Communications protocol From Wikipedia, the free encyclopedia (Redirected from Protocol (computing)) For other uses, see Protocol (disambiguation).
In telecommunications, a communication protocol is a system of rules that allow that two or more entities of acommunication system to communicate between them to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.[1] Communicating systems use well-defined formats (protocol) for exchanging messages. Each message has an exact meaning intended to elicit a response from a range of possible responses pre-determined for that particular situation. The specified behavior is typically independent of how it is to be implemented. Communication protocols have to be agreed upon by the parties involved.[2] To reach agreement, a protocol may be developed into a technical standard. Aprogramming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communications as programming languages are to computations.[3]
List of P2P protocols From Wikipedia, the free encyclopedia Contents [hide] 1 Protocols used by multiple programs 2 Protocols used by only one program 3 Programs not also listed as protocols 4 See also Protocols used by multiple programs[edit] Note that the name of the protocol may also be the name of the primary or original program that uses it. Ares (Ares Galaxy, Warez P2P) Bitcoin (Bitcoin, Alt-Coins) BitTorrent (ABC (Yet Another BitTorrent Client), BitComet, BitSpirit, BitTornado, BitTorrent.Net, G3 Torrent, mlMac, MLdonkey, QTorrent, Shareaza, Tribler, µTorrent, Vuze (previously Azureus) etc.) Direct Connect (BCDC++, DC++, NeoModus Direct Connect, etc.) FastTrack (Grokster, iMesh, Kazaa, Morpheus, etc.) eDonkey (eMule, Overnet, etc.) Gnutella (BearShare, iMesh, Gnotella, Gnucleus, GTK-gnutella, LimeWire, Frostwire, Mactella, Shareaza, etc.) MANOLITO/MP2PN (Blubster, Piolet, RocketItNet) OpenNap (Napigator, WinMX) RShare (RShare software, StealthNet) Protocols used by only one program[edit] 100Bao Aimster Applejuice Filetopia Freenet GnucleusLAN (a variant of Gnucleus) Goalbit GoBoogy Infinit KuGoo OpenFT (giFT) MUTE RetroShare Soribada Soulseek Xunlei Programs not also listed as protocols[edit]
This section may be confusing or unclear to readers. (March 2015) BearShare: Gnutella Blubster: MP2PN Gnotella: Gnutella Gnucleus: Gnutella Grokster: FastTrack GTK-gnutella: Gnutella iMesh: Gnutella, FastTrack Kazaa: FastTrack Limewire: Gnutella Mactella: Gnutella MXIE: BitTorrent, eDonkey, (?) Morpheus: FastTrack Piolet: MP2PN RocketItNet: MP2PN Shareaza: Gnutella, eDonkey, BitTorrent, HTTP, FTP WinMX: OpenNap, WPNP Vagaa: eDonkey, BitTorrent, (?) See also[edit]
Open Peer 1.Abstract The holy grail of communication on the Internet has been to allow peer-to-peer communication without the requirement of any centralized servers or services.A peer-to-peer approach offers some key advantages over a centralized server approach: Greater network resilience - peers can continue to function independent of servers and can operate even if servers are down Increased privacy and security - peers communicate directly thus the data is not centralized in one location where it can be spied upon by corporations, governments, 3rd parties or hackers. Decreased cost - without the need of servers, the cost to host, administer, store and relay data is reduced substantially Scalability - a peer to peer network doesn't require servers to scale as the peers can operate amongst themselves Unfortunately, the goal of peer-to-peer and the reality of peer-to-peer do not match. Centralization of data into the Internet cloud is prolific and firewalls frequently impede direct peer-to-peer communication making peer-to-peer connection extremely difficult to setup and challenging to architect. What further reduces the proliferation of peer-to-peer is a lack of standardization, openness and ubiquity of the technology. The standards bodies have been working for years on firewall traversal techniques and standardization of the approaches and a new joint effort called WebRTC between the W3C and IETF on how browsers can directly communication between browsers to move media. This joint effort does not specify how signaling happens between peers so it's not a complete solutions on its own. Performing peer-to-peer approach to signaling has been notoriously difficult for a variety of reasons: Without a publicly addressable intermediate 'server' machine to initiate communication, two peers behind firewalls are never able to communicate with each other. Thus, a peer network almost always requires some sort of rendezvous and relay servers to initiate contact between peers behind firewalls (and firewalls tend to be used more frequently than not for end users). Automatically promoting the few publicly addressable home machines into rendezvous and relay servers is not the best option. Average users tend to not want to have their home/work machines to be automatically promoted to rendezvous and relay servers since it consumes their bandwidth and costs them to relay traffic for others who "leech" off their bandwidth. This cost factor causes end users to intentionally shutdown protocols that promote end user machines into servers. Over time, the number of average users willing to have their machines operate as servers for the benefit of those leeching decreases relative to the number of those whom leech off those servers until the entire system collapses with a too great server/leech ratio. As an example, Skype's network collapsed for this very reason and they were forced to setup their own super nodes to handle the load. Some peer-to-peer networks require ports to be opened on a firewall to operate. Where possible, peers will register themselves with UPnP to open the ports when the firewall automatically. Unfortunately, many firewalls lack the ability to automatically open ports or actively disallow this feature for fear that this opens the network to security holes. If opening ports automatically is not possible then users are required to open ports manually. Thus only the technically savvy can perform this task and such peer networks tend to be limited to those who are technically savvy. This is not a universal solution since it assumes too much technical ability and responsibility of the end user. Many peer networks rely on mutual peers not behaving in an evil manner. Peers that do not act in an altruistic fashion can easily disrupt these networks. When all peers behave properly there is no problem with such a network; however, the moment an 'evil' node or cluster of 'evil' nodes is injected into the peer network, parts or all of the network can suffer fatal issues and security can be compromised. Open Peer is peer-to-peer signaling protocol taking advantages of the IETF advances of firewall penetration techniques for moving media and adds a layer to performs the media signalling in a peer-to- peer fashion but does expect that a minimal requirement of rendezvous servers existing. Beyond the initial rendezvous to get past firewalls, the servers should drop out of the protocol flow and are no longer required. Open Peer was designed with these main goals in mind: Openness - a protocol is freely available for anyone to implement. Greater network resilience - peers can continue to function and interoperate even if servers are down. Increased privacy and security - peers communicate directly in a secure fashion designed to protect against network ease dropping, forged communication or spying by 3rd parties or being a convenient data mining target for hackers as the information does not flow through centralized servers. Federation - the protocol makes it easy for users on one service to communicate with users on another independent service offering. Identity protection - the ability of users to easily provide proof of their identity using existing social platforms while protecting these identities from spoofed by others. Decreased cost - without the need to continuously relay signaling or media through centralized servers, the costs to host, administer, relay, replicate, process and store data on servers while providing 5 9s uptime is decreased. webRTC enabling protocol - designed to be the engine that allows webRTC to function, supporting federation of independent websites and services, provide security and online identity protection and validation, and peer-to-peer signaling bypassing the need for heavy cloud based infrastructure. Scalability - whether starting at 50 users or moving beyond 5,00,000 users, the protocol is designed to allow for easy scalability by removing the complexity of communications out of the servers. 2.Design Considerations The Open Peer Protocol has several design considerations to address the realities of the Internet infrastructure while delivering the functionality required: Must allow any peer to connect to any other peer (if authorized). Must understand firewall principles and to offer an architecture which factors that firewalls are prevalent and within the natural scope of the architecture's basic design. Must accept that it's not always desirable to have peer machines automatically promoted to rendezvous servers. Must allow additional services to be layered onto of the architecture Must enable peers to find each other using directory services. Must enable secure peer-to-peer communication without penetration or monitoring by third parties. Must allow peers to perform identity validations. Must allow anonymous peers, i.e. similar to unlisted and non-guessable phone numbers. Must allow for differing server rendezvous architectures, i.e. anywhere from peer-to-peer self-organized models to centralized network layouts are to be abstracted from the protocol. Must not require end user signed certificates from a known authority chain for each peers on the network to establish secure communications. Must not require end users or administrators to configure firewalls or open ports under normal circumstances. 3.Key Object Concepts 3.1.Identity An Identity is the persona of a peer contact, be they the representation of a real person or representative entity (much like a corporation is a legal entity but not a real person). An Identity maps to a single Peer Contact although a Peer Contact can have multiple Identities. 3.2.Asserted Identity An Asserted Identity is an identity that can be verified through an identity service as being the legal owner of the persona rather than a fraudulent representation. In other words, a validated asserted identity can be trusted that they are whom they claim to be. Different levels of identity assertion can be claimed for any given identity starting with no provable assertion at all and moving anywhere from weak to strong verification depending on the identity validation service types available. 3.3.Identity Lookup Server A server that looks up and returns the Peer Contact associated with an Identity or a set of Identities and can return the public profile information for Peer Contacts. 3.4.Identity Signing Service A service that provides the Asserted Identities for the various personas that are owned within a particular service offering. 3.5.Identity Provider Any service offering that grants Identity personas, such as Facebook, LinkedIn, Twitter or other 3rd parties that offer their own Identities. 3.6.Peer Contact A Peer Contact is the representation of a single point of contact on the Internet regardless of the personas represented by the peer contact. A peer contact can exist at zero or more Peer Locations at any given time. 3.7.Peer A Peer is the single instance of a peer client application on the Internet, which registers a single Peer Contact in the Peer Domain at a particular Peer Location. 3.8.Peer Location A Peer Location is the representation of where a peer is located. A Peer can only exist at a single location but the Peer Contact for the Peer can register at multiple Peer Locations. 3.9.Peer URI A Universal Resource Identifier (URI) starting with "peer:" offering the ability to locate a specific peer resource, protocol and request type within a peer domain. 3.10.Peer Domain A Peer is always connected to a Peer Domain and the domain is the organization responsible for managing the connected peers. 3.11.Peer Finder A Peer Finder is a rendezvous server that keeps track of connected peers at their peer locations since they are connected in a dispersed fashion through a peer domain. A peer finder will utilize a database (typically distributed) to facilitation the introduction of peer communication on the same domain or across domains. 3.12.Bootstrapper A Bootstrapper is the introductory server where peers first go to be introduced to one (or more) Peer Finders. Peers should attempt to connect to introduced Peer Finders in order to gain entry to the Peer Domain. Once a Peer is connected to a Bootstrapped Network, the Peer should no longer require communication back to the Bootstrapper unless access to previously introduced Peer Finders are no longer accessible. 3.13.Bootstrapped Network A Bootstrapped Network is the representation of the entire peering network that was introduced from a Bootstrapper. 3.14.Public Peer File A file that contains a cryptography public key for secure conversations, information required to locate the Peer Contact within a Peer Domain, information to authorize a connection to that Peer by another Peer and public Identities associated to a peer. Any Peer without the correct Public Peer File for another Peer Contact will be unable to connect to that peer. A directory service can host and offer these Public Peer Files between peers but without this file no communication is possible between peers (thus allowing for "unlisted" peers). 3.15.Private Peer File A file that contains a private key to be the pair of a public key inside the Public Peer file that is used by a Peer to be used to establish secure communications between Peers. The Private Peer File is encrypted and can only be decoded with the correct key. 3.16.Peer Pair A file pairing consisting of both a Public Peer File and a Private Peer File. 3.17.Provisioning Service A service that provides account creation and account profile maintenance. 3.18.Peer Service Any additional services offered to peers are done through what is called a Peer Service. Examples of such services are those that perform identity assertion, TURN or future services like video conferencing mixers.