In computer science, request–response or request–reply is one of the basic methods computers use to communicate with each other in a network, in which the first computer sends a request for some data and the second responds to the request. More specifically, it is a message exchange pattern in which a requestor sends a request message to a replier system, which receives and processes the request, ultimately returning a message in response. It is analogous to a telephone call, in which the caller must wait for the recipient to pick up before anything can be discussed. This is a simple but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel; it is especially common in client–server architectures.
For simplicity, this pattern is typically implemented in a purely synchronous fashion, as in web service calls over HTTP, which holds a connection open and waits until the response is delivered or the timeout period expires. However, request–response may also be implemented asynchronously, with a response being returned at some unknown later time. When a synchronous system communicates with an asynchronous system, it is referred to as "sync over async" or "sync/async". This is common in enterprise application integration (EAI) implementations where slow aggregations, time-intensive functions, or human workflow must be performed before a response can be constructed and delivered.
In contrast, one-way computer communication, which is like the push-to-talk or "barge in" feature found on some phones and two-way radios, sends a message without waiting for a response. Sending an email is an example of one-way communication, and another example are fieldbus sensors, such as most CAN bus sensors, which periodically and autonomously send out their data, whether or not any other devices on the bus are listening for it. (Most of these systems use a "listen before talk" or other contention-based protocol so multiple sensors can transmit periodic updates without any pre-coordination.
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
This advanced course will provide students with the knowledge to tackle the design of privacy-preserving ICT systems. Students will learn about existing technologies to prect privacy, and how to evalu
Explore les stratégies de résistance à la censure, y compris le mimétisme, le tunnelage et les chaînes secrètes, pour assurer l'accessibilité d'Internet face à la censure.
Explore Privacy Pass, une méthode pour contourner les défis d'Internet anonymement, discuter des concepts clés et répondre aux préoccupations de performance et d'évolutivité.
alt=|vignette|upright=1.8|Schéma de principe du mécanisme publish-subscribe Publish-subscribe (littéralement : publier-s’abonner) est un mécanisme de publication de messages et d’abonnement à ces derniers dans lequel les diffuseurs (publisher, littéralement éditeurs) ne destinent pas a priori les messages à des destinataires (subscriber, littéralement abonné). À la place, une catégorie est associée aux messages émis sans savoir s’il y a des destinataires.
Le protocole ou environnement client–serveur désigne un mode de transmission d'information (souvent à travers un réseau) entre plusieurs programmes ou processus : l'un, qualifié de client, envoie des requêtes ; l'autre, qualifié de serveur, attend les requêtes des clients et y répond. Le serveur offre ici un service au client. Par extension, le client désigne souvent l'ordinateur sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.
The management of IP networks is currently based on the SNMP protocol, and the use of expensive network management platforms designed according to the manager/agent paradigm of the SNMP framework. It uses two different schemes to transfer management data: ...
Fault tolerance can be achieved in distributed systems by replication. However, Fischer, Lynch and Paterson have proven an impossibility result about consensus in the asynchronous system model. Similar impossibility results have been established for atomic ...
2001
,
Peter Urban, Xavier Defago and Andre Schiper: Chasing the FLP Impossibility Result in a LAN or How Robust Can a Fault Tolerant Server Be? Keywords: replication, atomic broadcast, consensus, measurements, robustness, high load, LAN, FLP impossibility Abstra ...