This article is based on the analysis and writing of the broadcast module code of Laravel 5.4 version;
Recommended: "laravel tutorial"
Introduction
Broadcasting means that the sender sends a message, and each receiver who subscribes to the channel can receive the message in time; for example, student A writes an article, and student B comments under the article, and student A comments on the page You can receive notifications that an article has been commented on without refreshing. This essentially means that student A has received a broadcast message. This broadcast message is triggered by the action of student B commenting;
is broadcast throughout the entire broadcast. In behavior, there is an important concept called channel. The types of channels are
● Public channel public
● Private channel private
● Existence channel presence
If the mobile terminal subscribes to the public channel public, it will directly prompt success; during the subscription process of private channel private and existing channel presence, permission verification will be sent to the server to see if it has permission to subscribe to the channel; private channel private The difference from channel presence is that private channel private can receive messages sent by other members, while channel presence can also receive messages when users join and leave;
Broadcasting is suitable for the following scenarios (This small part is excerpted from Laravel event broadcast based on Pusher driver (Part 1)):
● Notification or Signal
Notification is the simplest example and the most commonly used arrive. Signals can also be seen as a form of notification, except that signals have no UI.
● Activity Streams
Activity Streams (feeds) are the core of social networks. For example, likes and comments in WeChat Moments, A can see B's likes in real time, and B can see A's comments in real time.
● Chat
Real-time display of chat information
Module composition
# #Demo
##Log driverConfiguration
.env file Modify or add a line: BROADCAST_DRIVER=log;
BroadcastDirect call
$manager = app(Illuminate\Broadcasting\BroadcastManager::class);
$driver = $manager->connection();
// 第一个参数是频道名,第二个参数是事件名,第三个参数是广播内容
$driver->broadcast(['channel_1', 'channel_2'], 'login', ['message' => 'hello world']);
[2017-08-18 20:45:49] local.INFO: Broadcasting [login] on channels [channel_1, channel_2] with payload: { "message": "hello world" }
This calling method is that when the event that implements the ShouldBroadcast interface is triggered, a broadcast operation will be performed ; (At the same time, there is also an interface called ShouldBroadcastNow. The difference from the ShouldBroadcast interface is that when events that implement the ShouldBroadcastNow interface are put into the queue, they will be put into the queue called sync)
For example,
The first step, the Illuminate\Auth\Events\Login event is an event that will be triggered after the user successfully logs in. Slightly change it to implement the broadcast function;
class Login implements ShouldBroadcast { ...... // 定义事件被触发时,广播频道;此处定义名为 first-channel 的私有频道 public function broadcastOn() { return [ new PrivateChannel('first-channel'), ]; } // 自定义广播名称;如果方法未定义,默认以类名为事件名,此处的默认值是 Illuminate\Auth\Events\Login public function broadcastAs() { return 'login'; } }
The second step, register Event monitoring; modify in app/Providers/EventServiceProvider.php:
protected $listen = [ ...... 'Illuminate\Auth\Events\Login' => [ 'App\Listeners\UserLogin', ], ];
The file app/Listeners/UserLogin.php is roughly implemented:
class UserLogin { public function __construct() {} public function handle(Login $event){ \Log::info('Do UserLogin Listener: I was Login'); } }
The third step is to trigger the event and send it Broadcast; there are several ways to trigger broadcast:
1. Direct event trigger
event(new Illuminate\Auth\Events\Login($user, true));
2. Help function broadcast, indirect trigger event
broadcast(new Illuminate\Auth\Events\Login($user, true));
3. Broadcast management class, Indirectly trigger events, broadcast directly
$manager = app(Illuminate\Broadcasting\BroadcastManager::class); $manager->event(new Illuminate\Auth\Events\Login($user, true));
4. Broadcast management class, indirectly trigger events, put them into the queue
$manager = app(Illuminate\Broadcasting\BroadcastManager::class); $manager->queue(new Illuminate\Auth\Events\Login($user, true));
Pusher is a For third-party services, when the server sends a broadcast, it will send a request to Pusher, and then interact with data through the long connection maintained by Pusher and the browser or mobile terminal;
ConfigurationRegister user information through the Pusher official website, obtain your own set of key information, and modify the .env configuration file;
BROADCAST_DRIVER=pusher PUSHER_APP_ID=xxxxxxxxxxxxxxxxxxxxxx PUSHER_APP_KEY=xxxxxxxxxxxxxxxxxxxxxx PUSHER_APP_SECRET=xxxxxxxxxxxxxxxxxxxxxx
Event Listening
Event monitoring in the background still uses the login example of the "Log Driven" part;
Front-endThe front-end page introduces the following code:
<script src="https://js.pusher.com/4.1/pusher.min.js"></script> <script> // 打开 Pusher 的调试日志 Pusher.logToConsole = true; // 定义 Pusher 变量 var pusher = new Pusher('PUSHER_APP_KEY的值', { cluster: 'ap1', encrypted: true }); // 定义频道,绑定事件 var channel = pusher.subscribe('private-first-channel'); channel.bind('login', function(data) { alert(data); }); </script>
If you subscribe to a public channel, you will not request permission check from the server; if it is a private channel (the channel name starts with private-) or there is a channel (the channel name starts with presence-), A permission check request will be issued; the corresponding backend needs to define the permissions of private channels and existing channels;
Channel permission definitionThe permission definition of the channel is in routes/ channels.php; here the author defines the permission callback function for the first-channel channel:
Broadcast::channel('first-channel', function ($user) { return (int) $user->id === 1; });
Some readers may wonder, isn’t the channel subscribed to by the front-end page private-first-channel? Why does the backend only define the permissions of the first-channel channel? That's because, assuming the channel defined by the backend is A, then the private channel passed in Pusher and the browser or mobile terminal is named private-A. If the channel exists, it will be presence-A;
Broadcast##Direct broadcast
$manager = app(Illuminate\Broadcasting\BroadcastManager::class); $driver = $manager->connection(); // socket 参数是广播私有频道时排除的 socket, 每个浏览器端或者移动端在建立 websocket 时都会被分配一个 socket_id $driver->broadcast(['private-first-channel'], 'login', ['user' => ['name' => 'hello'], 'socket' => '5395.4377611']);
Refer to the indirect broadcast mentioned in "Log Driven" Way;
If you want to send an exclusive broadcast (that is, no broadcast message will be received except for the client currently requesting), the following conditions are required:
1. The event uses the Illuminate\Broadcasting\InteractsWithSockets trait;
2. The request header sent by the front end must carry X-Socket-ID information;
3. The event triggers broadcast(new Illuminate\Auth\Events\Login($user, true)) ->toOthers();
Redis driver
Configuration
.env file Modify or add a line: BROADCAST_DRIVER= redis;
Broadcast
The principle is to also deploy a Socket.IO server on the backend. The Laravel framework will publish messages to the Socket.IO server, and the Socket.IO The server maintains a long connection with the browser or mobile terminal;
I haven’t demoed this part yet, and there are quite a lot of introductory materials online. If you know the principle, it will be much easier to get started with this part of the action;
The above is the detailed content of Detailed explanation of Laravel's broadcast module. For more information, please follow other related articles on the PHP Chinese website!