[db-wg] NRTM replication inefficiencies
- Previous message (by thread): [db-wg] NRTM replication inefficiencies
- Next message (by thread): [db-wg] NRTM replication inefficiencies
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Edward Shryane
eshryane at ripe.net
Fri Dec 8 15:10:28 CET 2017
Hi Job, > On 8 Dec 2017, at 13:51, Job Snijders <job at instituut.net> wrote: > > On Fri, Dec 08, 2017 at 12:56:11PM +0100, Edward Shryane wrote: >> We could also add an 'end-of-stream' comment in keep-alive mode, >> something like '%END (starting serial) - (ending serial)', which is >> output after any backlog of updates. > > Yeah, that would be useful. Is this easy low hanging fruit? > Yes, I've already tested it, this change is straightforward. The only downside is unexpected consequences (i.e. we don't want to break existing clients). >> It's still possible not to have any updates for a time, which a client >> may see as a timeout. We could also add a heartbeat mechanism, to >> periodically output a comment such as '%HEARTBEAT', if there have not >> been any updates. >> >> Do either of these changes necessitate a new protocol version? > > I doubt it, since "%END XXX - YYY" is a comment. > We could deploy a test NRTM version to our RC environment, for compatibility testing with existing clients. >> We could also provide NRTM over HTTP(S) WebSockets, that protocol >> includes support for a Ping/Pong heartbeat mechanism. > > Shouldn't we do away with NRTM at that point and come up with a > DELTA-like protocol? :) > > Kind regards, > > Job This is also possible (as a replacement, or in addition to, NRTM). Regards Ed
- Previous message (by thread): [db-wg] NRTM replication inefficiencies
- Next message (by thread): [db-wg] NRTM replication inefficiencies
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]