incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Remote service transport system
Date Tue, 28 May 2013 08:27:42 GMT
> Hi,
>> >
>> This sounds like a logical think to do. I'll just have to figure out how
>> to move mongoose from the Remote service admin to a new service. I guess
>> this should be the first step and after having done that add ZeroMQ from
>> an open-source project.
> In the past I started some work on this. If you could give me some time I
> can look it up and share. It is not finished, but could give a good
> starting point.

I would like to start working on the implementation tomorrow so I don't
know how much time you would need to look it up. Pepijn and I created the
attached header files to base the new implementation on. The handler will
be giving a server to a RS and a Connection to the connecting client. What
do you think about this way of implementing it?

>> The flow of the RSA,a transport service (TS), and a remote service (RS)
>> would then be:
>> 1: The RSA starts and listens for TS and RS
>> 2: The TS starts. The RSA now knows about the transport service
>> 3: The RS starts, Asks the RSA for an endpoint based on supplied
>> endpoint
>> description.
>> 4: RSA asks known TS if they are capable of setting up an endpoint with
>> supplied endpoint description.
>> 5: RSA asks one of the capable TS for an endpoint.
>> 6: TS sets up endpoint.
>> 7: RSA returns to RS with a status if the endpoint is created or not.
>> 8: The TS now listens for incoming requests and calls the callback
>> function supplied by the endpoint description and thus directly the RS.
>> 9: RS handles the function call and returns to the TS.
>> I think this is a logical way to handle the transport with remote
>> services. I do have some questions on what to do when the RSA stops.
>> 1: Should all the TS and RS stop as well or can they stay online?
> Stopping isn't needed I think, however.. If I am correct, the spec says
> that all endpoints are removed if a RSA is stopped. So if stopping implies
> this then yes. But if stopping means stopping a bundle then no.

Yes I meant removing the end points, closing connections and removing the
servers. The TS can still run.

>> 2: What should happen to an RS if the TS it uses stops? Stop the TS as
>> well or ask the RSA for a new TS if possible?
> Again, I think the spec should be leading here. As far as I know it is
> possible to have multiple endpoints for one remote service (based on
> configuration types), so asking for a new TS probably doesn't make sense.
> If there are multiple ts that can handle the configuration there are
> probably already multiple endpoints.
> Maybe it is a good idea to see a RSA TS and RS combination conceptually as
> one thing. If any of the three is gone, the others might need to "stop" as
> well. Stopping in this case is for a TS to remove the endpoints and for
> the
> RS to remove the broker.
> This gives:
> RSA gone: remove all endpoints and brokers created by that RSA. (there can
> be multiple RSA's).
> RS gone:
> Remove endpoints dependant on the RS. The broker is already gone as it is
> part of the RS.
> TS gone:
> Do nothing. The endpoints are already gone as part of the TS. The broker
> might as well be used by another TS, and the RSA might as well have
> exported different configuration  types.
> Having said that, is a RS only needed if there is a broker? And is the TS
> used for other cases? Eg when a new Tcp socket is used for each service?
> Or
> is the RS a service factory for those cases? If so, when the TS is gone,
> then the service created by the factory (for the endpoints of the TS)
> should be removed as well.

I think every service will get it's own TCP socket or transport server. I
think this is a better way to do it. If one socket gets blocked because it
is busy the other sockets still can handle data, unless of course the
interface is blocked.

>> Regards,
>> Erik Jansman

View raw message