send

Description :

mixed Connection::send(mixed $data [,$raw = false])

Envoie des données au client

Paramètres

$data

Les données à envoyer. Si un protocole est spécifié lors de l'initialisation de la classe Worker, la méthode encode du protocole sera automatiquement appelée pour effectuer l'encodage des données avant d'être envoyées au client.

$raw

Indique s'il faut envoyer des données brutes, c'est-à-dire sans appeler la méthode encode du protocole. La valeur par défaut est false, ce qui signifie que la méthode encode du protocole sera automatiquement appelée.

Valeur de retour

true signifie que les données ont été écrites avec succès dans le tampon d'envoi de socket du système d'exploitation pour cette connexion.

null signifie que les données ont été écrites dans le tampon d'envoi de la couche applicative de cette connexion, en attente d'être écrites dans le tampon d'envoi de socket du système.

false signifie que l'envoi a échoué, la raison de l'échec peut être que la connexion du client a déjà été fermée ou que le tampon d'envoi de la couche applicative de cette connexion est plein.

Attention

Le retour de send est true, cela signifie uniquement que les données ont été écrites avec succès dans le tampon d'envoi de socket du système d'exploitation pour cette connexion. Cela ne signifie pas que les données ont été envoyées avec succès dans le tampon d'envoi du socket de l'autre partie, et cela ne signifie pas non plus que l'application de l'autre partie a déjà lu les données à partir de son tampon de réception de socket local. Cependant, tant que send ne retourne pas false et que le réseau n'est pas déconnecté, et que le client reçoit normalement, les données peuvent essentiellement être considérées comme pouvant être envoyées à 100 % à l'autre partie.

Étant donné que les données du tampon d'envoi des sockets sont envoyées de manière asynchrone à l'autre partie par le système d'exploitation, et que le système d'exploitation ne fournit pas de mécanisme de confirmation correspondant à la couche applicative, la couche applicative ne peut pas savoir quand les données du tampon d'envoi des sockets ont commencé à être envoyées, et la couche applicative ne peut pas non plus savoir si les données du tampon d'envoi des sockets ont été envoyées avec succès. Pour ces raisons, Workerman ne peut pas fournir directement une interface de confirmation de message.

Si le business nécessite de garantir que chaque message a été reçu par le client, un mécanisme de confirmation peut être ajouté au niveau de l'application. Ce mécanisme de confirmation peut varier selon les différentes affaires, même le même mécanisme de confirmation peut avoir plusieurs méthodes.

Par exemple, un système de chat pourrait utiliser un tel mécanisme de confirmation. Chaque message est stocké dans une base de données, et chaque message a un champ indiquant s'il a été lu ou non. Chaque fois qu'un client reçoit un message, il envoie un paquet de confirmation au serveur, qui marque le message correspondant comme lu. Lorsque le client se connecte au serveur (généralement lors de la connexion de l'utilisateur ou de la reconnexion après une déconnexion), il interroge la base de données pour vérifier s'il y a des messages non lus. S'il y en a, le serveur les envoie au client, et lorsque le client reçoit le message, il notifie le serveur qu'il a été lu. Cela garantit que chaque message est bien reçu par l'autre partie. Bien sûr, le développeur peut également utiliser sa propre logique de confirmation.

Exemple

use Workerman\Worker;
use Workerman\Connection\TcpConnection;
require_once __DIR__ . '/vendor/autoload.php';

$worker = new Worker('websocket://0.0.0.0:8484');
$worker->onMessage = function(TcpConnection $connection, $data)
{
    // Appelle automatiquement \Workerman\Protocols\Websocket::encode pour emballer en tant que données de protocole websocket avant d'envoyer
    $connection->send("hello\n");
};
// Exécuter le worker
Worker::runAll();