You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 20, 2021. It is now read-only.
You should also retain connections with APNs across multiple notifications. APNs may consider connections that are rapidly and repeatedly established and torn down as a denial of-service attack.
Would it be better for Houston::Connection.open to cache connections been invocations? This approach is permitted by Apple:
You may establish multiple, parallel connections to the same gateway or to multiple gateway instances.
The text was updated successfully, but these errors were encountered:
I believe other gems that have tried to fulfill this requirement have gone the route of daemonizing the connection, sounds like a lot of work for low return. Maybe if you are sending hundreds or thousands of APNs then houston is a good fit but if you're planning on sending millions then you might want a service?
@matt I'd love to hear your thoughts on this it's something I've wondered about too.
I don't think it'd be much work. You would need two hashes in Houston::Connection -- one for the socket variable and one for the ssl variable. The key to the hashes would be the options parameter.
There's nothing inherently wrong with how Houston does its connection opening / closing—in fact, it's a Ruby convention to have a block parameter yielded to between setup and destroy (e.g. File#open).
Houston::Client doesn't attempt to do anything smart with pushing messages, as it's optimized for ease-of-use. However, if you wanted to keep the connection alive, you could rather easily make it so that the block executes indefinitely, keeping the connection open. This feels like the right approach anyway, as async / runloop / eventing code varies quite a bit across different applications (it may be useful to have a few documented examples of Houston integrating with something like Resque or Rails 4.0 queue)
All of that said, if you or anyone had a pull requests with suggestions on how this could be done better, I'd definitely like to see that.
In connection.rb,
Houston::Connection.open
opens and closes a TCP connection to Apple's servers each time it is called.However, page 47 of Apple's Local and Push Notification Programming Guide states the following:
Would it be better for
Houston::Connection.open
to cache connections been invocations? This approach is permitted by Apple:The text was updated successfully, but these errors were encountered: