4: Socket monitoring

Omdat elke verbinding via jouw hooks gaat, kun je sockets zien en beheren met gewone Phlo-modellen, zonder speciale tools nodig te hebben.

4.1: Aanwezigheid

Houd bij wie er verbonden is door een rij te schrijven in wsConnect en deze te verwijderen in wsClose:

function wsConnect($wsHost, $wsToken, $wsSocket){
	type_presence::create(socket: $wsSocket, token: substr((string)$wsToken, 0, 8), since: time())
	return true
}
function wsClose($wsHost, $wsToken, $wsSocket){
	type_presence::delete('socket=?', $wsSocket)
}

De live telling is dan gewoon count(type_presence::records()), die je naar iedereen kunt uitzenden bij elke wijziging.

4.2: Een connect/disconnect feed

Voeg elk lifecycle-evenement toe aan een logmodel en je hebt een audittrail en een live feed. De /monitor pagina van de demo rendert de log en werkt de online telling en de feed bij via wsCast terwijl sockets komen en gaan.

4.3: Health

A GET /health on the daemon (e.g. 127.0.0.1:3001) reports both the connection side and the worker pools in one place, since they are one process:

{
	"status": "ok",
	"workers": 5,
	"cap": 7,
	"pools": {
		"/var/www/app/release/www/app.php": { "workers": 4, "busy": 2, "queued": 0 }
	},
	"sockets": {
		"app.example.com": {
			"tokens": 5,
			"sockets": 12,
			"perToken": { "9c11922f8c7fff2d...": 2 }
		}
	},
	"registered": ["app.example.com", "dev.example.com"]
}

sockets counts the live connections per host (tokens and sockets); pools is the per-app worker stats, where busy is the workers currently handling an event and queued the events waiting for a free worker; workers/cap is the live total against the ceiling. The pool grows itself toward the cap and reaps idle workers, so a busy that sits at the cap with a growing queued means the node is at capacity.

Presence

perToken breaks the count down per connected token, which is what you need to answer "is that user connected", as opposed to how many are. The keys are sha256 of the token, never the token itself: the endpoint is readable by any process on the box and a token is a credential. Your app knows its own tokens, so it hashes each one and looks it up.

Read presence here rather than counting it yourself in the hooks. A tally kept in your own database cannot stay right: a hard restart of the daemon never fires the closes, and the late closes of the old connections then cancel out the reconnects, so live clients end up looking offline. The daemon holds the sockets, so it is the only source that cannot drift. Store the connect and close moments if you want a timeline, and ask the daemon for the current state.

4.4: Beperkingen

Phlo Realtime is de ingebouwde WebSocket-laag van de daemon: één proces beheert de sockets en draait de PHP. In de one-shot modus (een build: true app) start de daemon een handler per gebeurtenis, waardoor er een kleine kosten per gebeurtenis is in vergelijking met een proces dat staat in het geheugen; draai de host als een release build en de daemon serveert het vanuit zijn residentiële pool, waardoor die kosten worden verwijderd en de doorvoer wordt geschaald. Hoe dan ook, je behoudt hetzelfde stateless model als de rest van Phlo en er is geen extra taal. Voor zeer hoge frequentie streaming (veel gebeurtenissen per seconde per socket) kan een dedicated streaming server nog steeds beter passen.

Laatst bijgewerkt op 07-10-2026