- What is workerman/channel used for?
- workerman/channel is a lightweight inter-process communication component for PHP built on Workerman. It provides a Channel\Server and Channel\Client that let multiple worker processes publish and subscribe to named events over TCP or Unix sockets. It is intended for long-running Workerman applications that need asynchronous, non-blocking event fan-out without shared memory.
- Is workerman/channel a Laravel package, and which Laravel versions does it support?
- No. workerman/channel ships no Laravel service provider, config file, facade, or Laravel version constraints; it is a two-class IPC primitive for Workerman. You can install it in a Laravel project, but any service provider, config, and lifecycle glue are yours to build. Because it does not declare Laravel constraints, compatibility depends on your PHP and Workerman versions rather than Laravel 10, 11, or 12.
- How do I install workerman/channel with Composer?
- Run composer require workerman/channel in the project that will run the channel server and clients. The package is small and has no Laravel auto-discovery, so there is nothing to register after installation. You must also ensure Workerman is installed and pinned to the major version your wrapper is tested against.
- How do I configure and run the workerman/channel server in Laravel?
- You typically create a supervised Artisan command such as channel:serve that instantiates Channel\Server on a TCP port or Unix domain socket inside a Workerman worker loop. Add a config file for the socket path or port, timeouts, event names, and graceful shutdown, plus stale-socket cleanup. Laravel does not provide this command or configuration out of the box.
- How do I publish and subscribe between Laravel queue workers or Artisan commands?
- Each long-lived process creates a Channel\Client, connects to the server, subscribes to named events, and publishes payloads to those events. You need to own connect-on-boot, onConnect re-subscription, reconnect and backoff, heartbeat handling, and an internal event-name and payload contract. The package gives you a string event name and an arbitrary PHP value with no schema.
- Does workerman/channel work with Laravel Octane?
- It can run alongside Octane, but it is only a partial fit. Octane's Swoole, RoadRunner, and FrankenPHP workers already have their own IPC and table primitives, and adding a second unrelated IPC substrate increases complexity. Use it only if you already have a separate Workerman service that needs cross-process fan-out.
- Is workerman/channel secure for production use?
- The channel server has no authentication, authorization, or transport encryption. Any process that can reach the socket can subscribe to and publish on any event, so a Unix domain socket with restrictive filesystem permissions should be mandatory. Avoid exposing a TCP port on a non-loopback interface unless you add your own access controls.
- What are the reliability and scaling limits of workerman/channel?
- The server is a single process and a single point of failure; if it dies, clients silently lose subscriptions until reconnect logic fires. Publishing is fire-and-forget with no delivery acknowledgement, no per-subscriber queue, and no backpressure signal for slow subscribers. Message size is bounded by the socket read buffer, so it is not appropriate for large payloads.
- Can workerman/channel replace Redis pub/sub or Laravel broadcasting?
- No, it is not a drop-in replacement. It has no durability, persistence, delivery acknowledgement, or managed cross-host transport, unlike Redis pub/sub or Laravel's broadcast system. If you need a durable, managed broker for a typical Laravel app, Redis is usually the stronger choice; workerman/channel only makes sense when you are already committed to Workerman and want to avoid one infrastructure dependency.
- How do I test a workerman/channel integration in Laravel?
- Test the server and client lifecycle with integration tests that start a real Channel\Server on a temporary Unix socket or loopback port, then assert subscribe, publish, reconnect, and shutdown behavior. Unit-test your event-name and payload contracts separately, and pin and test against a specific Workerman major because the 4.x to 5.x transition changed event-loop and worker APIs. Also account for the package being effectively a one-maintainer project with low independent scrutiny.