Hello!
To use the forum, login or register above.
(If you are already logged in above, please click here)
API notification push/poll
I have been working on some inventory synchronization software (it will be open-source once complete, tested and user-friendly enough... but it's not there yet).
I'm wondering, what would be the preferred way to obtain notification of new BrickOwl orders?
For polling, the server's current HTTP 1.1 Keep-alive timeout seems to be about 1.2 seconds, so keeping that socket alive is out of the question. The SSL handshake itself (on top of the TCP handshake) is heavy in processing and bandwidth, so it's slightly wasteful to reconnect every minute. Raising the server's Keep-alive timeout is of course not recommended (memory consumption becomes massive with many connections due to the large socket buffers required for ordinary HTTP traffic).
Pushing notifications from the server by connecting to a custom address wouldn't be too user-friendly (requires properly configured routers/firewalls, etc.). That can still work nicely though, if the API allows updating the notification address/port for sellers with non-static IPs.
A good and probably overkill solution might be an independent server process managing many long-lived sockets with tiny 4kb internal buffers by epoll(). Clients would connect and await the "something happened!" messages among the regular ping/pong every few minutes (traffic would be of no interest, so no need for SSL which would eat an extra 100kb per socket). Definitely overkill though.
Okay, I'm rambling...
What's the preferred long-term solution, looking ahead to future growth and possibly hundreds of sellers desiring notifications?
I'm wondering, what would be the preferred way to obtain notification of new BrickOwl orders?
For polling, the server's current HTTP 1.1 Keep-alive timeout seems to be about 1.2 seconds, so keeping that socket alive is out of the question. The SSL handshake itself (on top of the TCP handshake) is heavy in processing and bandwidth, so it's slightly wasteful to reconnect every minute. Raising the server's Keep-alive timeout is of course not recommended (memory consumption becomes massive with many connections due to the large socket buffers required for ordinary HTTP traffic).
Pushing notifications from the server by connecting to a custom address wouldn't be too user-friendly (requires properly configured routers/firewalls, etc.). That can still work nicely though, if the API allows updating the notification address/port for sellers with non-static IPs.
A good and probably overkill solution might be an independent server process managing many long-lived sockets with tiny 4kb internal buffers by epoll(). Clients would connect and await the "something happened!" messages among the regular ping/pong every few minutes (traffic would be of no interest, so no need for SSL which would eat an extra 100kb per socket). Definitely overkill though.
Okay, I'm rambling...
What's the preferred long-term solution, looking ahead to future growth and possibly hundreds of sellers desiring notifications?
Powered by Vanilla
Comments
There's no rush for that particular feature yet, but some pushing mechanism would be a good idea eventually.
Thanks Lawrence for the great API and all your efforts.