Les serveurs pair-à-pair fonctionnent dans la quasi-totalité des cas en mode synchrone : le transfert d'information est limité aux éléments connectés en même temps au réseau.
Ils peuvent utiliser le protocole TCP comme couche de transport des données (il fonctionne en duplex, la réception des données est donc confirmée et leur intégrité est assurée).
En revanche, certaines utilisations comme le continu (streaming) nécessitent l'emploi d'un protocole plus léger et plus rapide, comme UDP, bien que moins fiable, quitte à assurer eux-mêmes l'intégrité des données transmises. UDP est aussi le protocole le plus utilisé pour transmettre des messages entre serveurs dans les systèmes en partie centralisés.
Les systèmes pair-à-pair se répartissent en plusieurs grandes catégories, selon leur organisation.
Dans cette architecture, un client (un logiciel utilisé par les membres) se connecte à un serveur qui gère les partages, la recherche, l'insertion d'informations, bien que celles-ci transitent directement d'un utilisateur à l'autre.
Certains considèrent que de telles architectures ne sont pas pair-à-pair, car un serveur central intervient dans le processus. D'autres leur répondent que les fichiers transférés ne passent pas par le serveur central. C'est la solution la plus fragile puisque le serveur central est indispensable au réseau. Ainsi, s'il est supprimé, à la suite d'une action en justice par exemple, comme ce fut le cas avec Napster et Audiogalaxy, tout le réseau s'effondre.
Une telle architecture permet de résister à de telles attaques puisque le logiciel client ne se connecte pas à un unique serveur mais à plusieurs. Le système est ainsi plus robuste mais la recherche d'informations est plus difficile. Elle peut s'effectuer dans des systèmes décentralisés non-structurés, comme Gnutella, où la recherche nécessite un nombre de messages élevé, proportionnel au nombre d'utilisateurs du réseau (et exponentiel suivant la profondeur de recherche). Dans les systèmes décentralisés structurés, une organisation de connexion est maintenue entre les nœuds. La plupart est basée sur les table de hachage distribuées, permettant de réaliser des recherches en un nombre de messages croissant de façon logarithmique avec le nombre d'utilisateurs du réseau, comme CAN, Chord, Freenet, GNUnet, I2P, Tapestry, Pastry et Symphony.
Une autre solution a été envisagée, consistant en l'utilisation de « super-nœuds », éléments du réseau choisis en fonction de leur puissance de calcul et de leur bande passante, réalisant des fonctions utiles au système comme l'indexation des informations et le rôle d'intermédiaire dans les requêtes. Cette solution, rendant le système un peu moins robuste (les cibles à « attaquer » dans le réseau pour que le système devienne inopérant sont moins nombreuses que dans un système de type Gnutella, par exemple), est employée dans les systèmes FastTrack, comme KaZaA. Les nœuds du réseau peuvent alors devenir super-nœuds et vice-versa, selon les besoins du système ou de leur propre choix.
De la même façon, le système eDonkey2000 utilise des serveurs fixes, plus vulnérables car moins nombreux et moins souple que les super-nœuds FastTrack.
Les connexions se font par TCP/IP, le plus utilisé sur internet, qui intègre un contrôle de réception des données, ou par UDP lorsque l'application choisit de contrôler elle-même la bonne réception des données.
Plusieurs systèmes pair à pair sont proposés sous forme de réseau abstrait, même s'ils ne sont pas tous, en 2009, très répandus. Les applications proposées à l'utilisateur final fonctionnent à l'aide de tels protocoles réseaux.
Parmi eux, on trouve Mnet, Chord, Tapestry, Freenet, I2P (utilisé par iMule), Tor ou Koorde (en).