> On 1 Nov 2017, at 15:19, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > > There's sort of two pieces here, right? > 1) From the Dispatcher perspective, we want a single "Messenger" that > it talks to. (At least, I'm pretty sure. Unless we need to be making > routing decisions using internal data? I really hope that never comes > up.) That could be set up by having multiple Messenger implementations > behind a "UnifyingMessenger" abstraction layer with pretty minimal > changes. I agree, with the current code the solution would be to share the same dispatcher across multiple messenger instances. > > 2) From an implementation perspective, which data structures do we end > up needing to share in order to have a daemon listening on multiple > ports? > > So, from the SimpleMessenger perspective, I don't think we get much > out of trying to build multi-bind into it. We'd basically get to > eliminate the duplicated DIspatchQueue, which is not very interesting. > (Modulo some flow control stuff, perhaps.) From an AsyncMessenger > implementation perspective, that calculus might shift since we're > running on a thread pool, but I'm not deeply familiar with the code > internals. > > But I'm curious what brings this up. I thought you were working on the > v2 protocol — does something in that somehow hinge on the server-side > implementation of multiple networks? I remembered this while talking with Joao about why the Mons bind to a single network interface even if in ceph.conf the public_network value contains multiple networks. Then I thought that maybe the mons only bind to a single interface because it would be too cumbersome to start a single messenger for each network interface and manage the shared dispatcher. Therefore, since I was already making changes to the async messenger implementation, I could see if it was easy to support multiple-bind in the messenger code and make this functionality available to other modules with minimal code changes. The V2 protocol implementation does not depend on the multiple bind functionality, so I would just implement it if people would find it very useful. > -Greg
Attachment:
signature.asc
Description: Message signed with OpenPGP
