Probably just write raw data in the packet
I believe endianness won't allow using raw data.
2014-08-25 13:11 GMT+04:00 Alex Hermann alex@speakup.nl:
On Friday 22 August 2014, Charles Chance wrote:
On 22 August 2014 16:46, Alex Hermann alex@speakup.nl wrote:
Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in.
Can you expand a little on "the state dmq was in"?
I was hoping to use it as-is, but i encountered issues which had to be resolved before i could even use the module:
- As soon as i enabled the dmq module, i experienced segfaults.
- It had bad interaction with the maxfwd module
- Status updates between hosts were largely ignored.
- The configured server_address wasn't used to send messages.
It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review.
Looking forward to seeing it - may save me the time :)
I pushed my WIP to the branch alexh/dialog-sync-wip which also contains dialog and dmq fixes and cleanups.
It's WIP, so it might still change. This branch is only compile-tested so far, because i normally develop against 3.2. I just cherry-picked most of my patches to master.
Known issues:
- Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.
Still on the TODO list:
- Delete 'disabled' dmq hosts
- Cope better with out-of-order sync messages
- Sync initial state
- Clean shutdown of DMQ, free all memory
- More efficient protocol instead of JSON. Probably just write raw data in
the packet, so the receiving side can just use a pointer into the buf instead of having to copy everything.
-- Alex
-- Alex Hermann
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev