Closed dbrgn closed 6 years ago
No. Pooling happens already in hyper, and with h2 pooling means one connection, because you can send multiple requests without waiting for responses, so it's async by nature.
The six connections for us is if one server crashes, we have five more to handle the load. It's more like a reminder that don't go wild with connections, one is usually enough for scaling purposes and for redundancy, you do well having six servers.
Ah, you started 6 separate processes, not 6 threads inside the same process, correct? :slightly_smiling_face:
True. If you want to serve more iOS apps from the same process, you'd need more connections preferably in different threads.
And funny now when I think about this, you'd expect to be able to send notifications to different applications when using token-based authentication, but Apple confirmed this that you must always use a different connection, the token-based ones just give you an error when your key doesn't match to the first notification sent through that pipe (hence I forbid that on the type level)...
:smile: apple.
Ok, that makes sense :slightly_smiling_face: Then I'll just start two processes on two separate servers (one connection per server), that should be enough for my use case.
Yeah, and you can scale up to somewhere around 64 connections, at least we could when we still were using solicit for sending. Be aware though, they will throttle and punish you at some point. When? Nobody knows.
In the README you write:
Since you recommend using multiple connections, could this library maybe add support for connection pools? Alternatively this could also be done as a separate crate.
Do you have any recommendation on how to implement such a pool? A thread per connection with its own reactor core, with channels to trigger pushes?
I also thought about writing a r2d2 backend: https://github.com/sfackler/r2d2 But r2d2 is targeted at databases, I'm not sure if the trait is suited for APNs connections.