Aller-retour (X11)
Une requête qui doit attendre la réponse du serveur avant que le programme puisse continuer : l'opération la plus coûteuse du protocole X, et la raison pour laquelle une boîte à outils pouvait mettre des secondes à démarrer sur une liaison lente.
La plupart des requêtes X, tracer une ligne, déplacer une fenêtre, n'ont pas de réponse ; Xlib les met en file dans un tampon et les envoie par lots. Mais XInternAtom, XGetWindowAttributes, XQueryTree, XGetGeometry et XSync exigent une réponse, et Xlib bloque jusqu'à son arrivée. En local, sur un socket Unix, cela prend une fraction de milliseconde ; sur un réseau avec 50 ms de latence, chaque requête de ce type est un vingtième de seconde d'immobilité. Une application Motif pouvait enregistrer des centaines d'atomes et interroger la géométrie de chaque widget au démarrage, d'où les attentes familières sur les terminaux X et via modem.
Les remèdes ont été nombreux. Xlib a gagné XInternAtoms pour obtenir de nombreux atomes en une seule réponse. LBX, puis NX, ont placé à côté du serveur un proxy qui répondait depuis un cache. XCB a été construit en 2001 précisément pour cela : chaque requête renvoie aussitôt un cookie et la réponse n'est récupérée qu'au moment voulu, de sorte que dix questions peuvent être en vol en même temps. Les boîtes à outils ont appris à mettre en cache les attributs des fenêtres au lieu de les redemander. La gestion des erreurs est un cas particulier : les erreurs étant signalées de façon asynchrone, un programme ne sait qu'un appel a échoué qu'à l'aller-retour suivant, ce qui rend le gestionnaire d'erreurs X si difficile à raisonner.