send

설명:

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

클라이언트에 데이터 전송

매개변수

$data

전송할 데이터이며, Worker 클래스를 초기화할 때 프로토콜을 지정하면 프로토콜의 encode 메소드가 자동으로 호출되어, 프로토콜 패킹 작업을 완료한 후 클라이언트에 전송합니다.

$raw

원시 데이터를 전송할지 여부, 즉 프로토콜의 encode 메소드를 호출하지 않도록 지정하는 것으로, 기본값은 false로 프로토콜의 encode 메소드가 자동으로 호출됩니다.

반환값

true는 데이터가 해당 연결의 운영 체제층의 socket 전송 버퍼에 성공적으로 기록되었음을 나타냅니다.

null은 데이터가 해당 연결의 애플리케이션층 전송 버퍼에 기록되었으며, 운영 체제층 socket 전송 버퍼에 기록되기를 기다리고 있음을 나타냅니다.

false는 전송 실패를 나타내며, 실패 원인은 클라이언트 연결이 이미 종료되었거나 해당 연결의 애플리케이션층 전송 버퍼가 가득 찼기 때문일 수 있습니다.

주의

send가 true를 반환한다고 해서 데이터가 해당 연결의 운영 체제 socket 전송 버퍼에 성공적으로 기록되었음을 의미하며, 데이터가 상대방 socket 수신 버퍼에 성공적으로 전송되었음을 또는 상대방 애플리케이션 프로그램이 로컬 socket 수신 버퍼에서 데이터를 읽었음을 의미하지는 않습니다. 그렇지만 send가 false를 반환하지 않고 네트워크가 끊어지지 않으며 클라이언트가 정상적으로 수신할 수 있다면, 데이터는 기본적으로 상대방에게 100% 전송될 수 있다고 봐도 무방합니다.

socket 전송 버퍼의 데이터는 운영 체제에 의해 비동기적으로 상대방에게 전송되며, 운영 체제는 애플리케이션层에 해당 확인 메커니즘을 제공하지 않기 때문에, 애플리케이션层은 socket 전송 버퍼의 데이터가 언제 전송되기 시작하는지 알 수 없으며, 애플리케이션层은 socket 전송 버퍼의 데이터가 성공적으로 전송되었는지 알 수도 없습니다. 이러한 이유로 workerman은 직접적인 메시지 확인 인터페이스를 제공하지 않습니다.

비즈니스에서 각 메시지가 클라이언트에 수신되었음을 보장해야 하는 경우, 비즈니스적으로 확인 메커니즘을 추가할 수 있습니다. 확인 메커니즘은 비즈니스에 따라 다를 수 있으며, 동일한 비즈니스의 확인 메커니즘도 여러 가지 방법이 있을 수 있습니다.

예를 들어 채팅 시스템은 다음과 같은 확인 메커니즘을 사용할 수 있습니다. 각 메시지를 데이터베이스에 저장하고, 각 메시지에는 읽음 여부의 필드가 있습니다. 클라이언트가 메시지를 수신할 때마다 서버에 확인 패키지를 전송하고, 서버는 해당 메시지를 읽음으로 설정합니다. 클라이언트가 서버에 연결할 때(일반적으로 사용자가 로그인하거나 연결이 끊어질 때 재연결), 데이터베이스에 읽지 않은 메시지가 있는지 조회하고, 있다면 클라이언트에 전송합니다. 클라이언트가 메시지를 수신한 후 서버에 읽음 알림을 전송합니다. 이렇게 하면 각 메시지가 상대방에게 수신되도록 보장할 수 있습니다. 물론 개발자는 자신의 확인 논리를 사용할 수도 있습니다.

예제

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)
{
    // 자동으로 \Workerman\Protocols\Websocket::encode를 호출하여 websocket 프로토콜 데이터로 패킹 후 전송
    $connection->send("hello\n");
};
// worker 실행
Worker::runAll();