[Info] Pub/sub feature tracking

[ghost]

Tracking all issues with pub/sub

-> I have thought a lot about pub/sub and I have a few strategies I am considering,

• It needs to merge multiple sends on a per-socket basis so that publishing to two or more topics gets merged as one syscall per socket.
• It still needs to be fast for the case where there only is one topic published to for one socket.
• Iterating over all sockets is slow in a linked list, but faster than doing an extra syscall for every socket. Needs to be balanced; only iterate if absolutely necessary.

Bugs:

914 <- one publish can resolve into many topics (such as wildcards)

937 <- yes, this is currently very broken

Status is currently very broken, and I do not know how relevant this support is right now anymore

[ghost]

I've thought about this a lot and the simplest solution seems to perform very good:

• Every Topic holds a Set (red-black tree) of Sockets (pointers).
• Every socket also holds a linked list of what Topics it subscribes to.
• Subscription is logarithmic in time
• When publishing to a Topic, that topic is marked as "triggered"
• When about to end the loop iteration, all triggered Topics are put in a vector (or whatever)
• All sets of all triggered Topics are iterated over in order, determining their respective intersection with one another (if one socket exists in 2 topics, that socket knows about this intersection).
• Every involved socket is thus iterated over in order, knowing exactly what messages from what Topics it should send, in one single syscall.
• Failure to send everything, results in backpressure stored in the Topics, but referred to by the Subscription
• When a socket is writable it checks its backpressure and tries to reduce it

Something like that, I haven't thought about every detail but iterating 3 million sockets across 3 Sets takes less than 15% of the time syscalls take so that is a negligible cost (it can even go down to practially free if sockets are stored in sorted vectors, but sets are fine).

[ghost]

lexhultman@clr-9c9c4beff725453db9688b589234d573~/uWebSockets.js/uWebSockets/benchmarks $ ./broadcast_test 40 localhost 9001 0
Running benchmark now...
Iterations/second (40 clients): 2300.750000
Iterations/second (40 clients): 2308.000000
Iterations/second (40 clients): 2304.250000
Iterations/second (40 clients): 2300.000000
Iterations/second (40 clients): 2306.000000
Iterations/second (40 clients): 2303.500000
Iterations/second (40 clients): 2304.500000
Iterations/second (40 clients): 2305.500000
^C
alexhultman@clr-9c9c4beff725453db9688b589234d573~/uWebSockets.js/uWebSockets/benchmarks $ ./broadcast_test 40 localhost 9001 0
Running benchmark now...
Iterations/second (40 clients): 2712.250000
Iterations/second (40 clients): 2724.000000
Iterations/second (40 clients): 2719.250000
Iterations/second (40 clients): 2716.000000

New pubsub is currently 2300 vs. former 2700 however things can be optimized a lot. This implementation at least does things reasonably correct.