You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@etch.apache.org by Prashant Shewale <pv...@gmail.com> on 2011/04/14 13:17:13 UTC
Query regarding client discovery
Hi,
First of all thanks for such a wonderful framework. I have recently found
this while searching and really liked it.
I am trying to use this for one of my application in which application on
multiple client nodes will be centrally managed from single server. To
establish connection between client and server we have two use cases.
1. First one is to start server initially and then start client by providing
IP address and port number of server to connect. This looks straightforward
with Etch and I was able to do that successfully.
2. Another case is to server may have started initially or not, but start
client with no information about server. The client will just keep running
and listening. Then user will fire discovery from server interface by
providing range of IP address in the network and then server will contact
etch IP address and try to establish connection with client. This may be
giving request to client to make connection on blah blah server on blah blah
port.
Is it possible to achieve #2 case above by any means in Etch framework
itself?
Thanks,
Prashant
Re: Query regarding client discovery
Posted by Prashant Shewale <pv...@gmail.com>.
Thanks Holger for quick reply. Unfortunately I don't have "always available
machine" in my scenario. Will try out Bonjour solution.
On Thu, Apr 14, 2011 at 5:30 PM, Holger Grandy
<Ho...@bmw-carit.de>wrote:
> Hello Prashant,
>
>
>
> Etch currently has no special discovery mechanism built in. What you could
> do is to run another Etch service on a
>
> machine that is always available (if such a machine exists in your
> scenario) and use Etch itself to query the
>
> name / ip / port of the currently active “central server” of your
> application. Like a central registry of endpoints,
>
> where peers can query details on other active peers. You would have to
> model this as another Etch service, of course.
>
> There are some ideas regarding that in the Roadmap section on the website.
>
>
>
> Another (quick-win) thing that you could do is to use an existing discovery
> mechanism like Bonjour / ZeroConf
>
> and announce your services using that.
>
>
>
> Cheers,
>
> Holger
>
>
>
>
>
> *From:* Prashant Shewale [mailto:pvshewale@gmail.com]
> *Sent:* Donnerstag, 14. April 2011 13:17
> *To:* etch-user@incubator.apache.org
> *Subject:* Query regarding client discovery
>
>
>
> Hi,
>
>
>
> First of all thanks for such a wonderful framework. I have recently
> found this while searching and really liked it.
>
>
>
> I am trying to use this for one of my application in which application on
> multiple client nodes will be centrally managed from single server. To
> establish connection between client and server we have two use cases.
>
>
>
> 1. First one is to start server initially and then start client by
> providing IP address and port number of server to connect. This looks
> straightforward with Etch and I was able to do that successfully.
>
> 2. Another case is to server may have started initially or not, but start
> client with no information about server. The client will just keep running
> and listening. Then user will fire discovery from server interface by
> providing range of IP address in the network and then server will contact
> etch IP address and try to establish connection with client. This may be
> giving request to client to make connection on blah blah server on blah blah
> port.
>
>
>
> Is it possible to achieve #2 case above by any means in Etch framework
> itself?
>
>
>
> Thanks,
>
> Prashant
>
RE: Query regarding client discovery
Posted by Holger Grandy <Ho...@bmw-carit.de>.
Hello Prashant,
Etch currently has no special discovery mechanism built in. What you could do is to run another Etch service on a
machine that is always available (if such a machine exists in your scenario) and use Etch itself to query the
name / ip / port of the currently active "central server" of your application. Like a central registry of endpoints,
where peers can query details on other active peers. You would have to model this as another Etch service, of course.
There are some ideas regarding that in the Roadmap section on the website.
Another (quick-win) thing that you could do is to use an existing discovery mechanism like Bonjour / ZeroConf
and announce your services using that.
Cheers,
Holger
From: Prashant Shewale [mailto:pvshewale@gmail.com]
Sent: Donnerstag, 14. April 2011 13:17
To: etch-user@incubator.apache.org
Subject: Query regarding client discovery
Hi,
First of all thanks for such a wonderful framework. I have recently found this while searching and really liked it.
I am trying to use this for one of my application in which application on multiple client nodes will be centrally managed from single server. To establish connection between client and server we have two use cases.
1. First one is to start server initially and then start client by providing IP address and port number of server to connect. This looks straightforward with Etch and I was able to do that successfully.
2. Another case is to server may have started initially or not, but start client with no information about server. The client will just keep running and listening. Then user will fire discovery from server interface by providing range of IP address in the network and then server will contact etch IP address and try to establish connection with client. This may be giving request to client to make connection on blah blah server on blah blah port.
Is it possible to achieve #2 case above by any means in Etch framework itself?
Thanks,
Prashant
AW: Query regarding client discovery
Posted by Ka...@bmw.de.
Hi Prashant,
we implemented an Etch RPC-based service management recently that finds
services matching a known service ID (no fancy service selection or the
like). It basically consists of a standard service that participating clients
and servers use as a library. This works over a central
directory server - like Holger proposed below - or alternatively via UDP
broadcasting (if broadcasting is possible in your network?).
Today we uploaded code and documentation for using Etch over UDP to the Etch JIRA which is a prerequisite for our service management solution (see https://issues.apache.org/jira/browse/ETCH-157). We assume that we will be ready to provide the service management code and documentation in approx. two weeks - given that the community has accepted our UDP contribution until then.
-Kay
-----Ursprüngliche Nachricht-----
Von: scott comer [mailto:wert1y@mac.com]
Gesendet: Freitag, 15. April 2011 16:19
An: etch-user@incubator.apache.org
Betreff: Re: Query regarding client discovery
hi prashant,
two years ago we started defining an etch naming service, there might be
stuff in the wiki or even in the source code about that. that work has
been dormant since then.
we are (at spawnlabs) resurrecting that work with an eye to our own use.
but i would make as much of the code public as possible.
here's the idea, loosely:
normally one opens a client session using a uri such as this:
tcp://host:port?filter=blah
if you then deploy a bunch of clients, then they are pretty well bound
to have trouble when you need to change host, port, or the filters. and
certainly if you decided you wanted to use the tls scheme instead. so,
rather than use the raw uri spec for the connection, what if you use a
uri like this:
etch:my-service-type/my-service-name
and somewhere else could specify a mapping:
my-service-type/my-service-name = tcp://host:port?filter=blah
that mapping could be in a defined local file or resource or in a remote
service. we defined such a remote service
and gave it an api and demonstrated this technique.
the etch scheme, then, selects a TransportFactory which knows how to use
that api to find the requested service uri by using the defined
NameService api.
obvious extension is to allow a query instead of just a name, say based
on service type, locality, etc.
how do you find the NameService itself?
dhcp? system property? broadcast lookup? bonjour? endless possibilities...
best, though, would be to use the defined NameService api and scheme, if
that works for you. if not, let's figure out why not and fix it.
scott out
On 4/14/2011 6:17 AM, Prashant Shewale wrote:
> Hi,
>
> First of all thanks for such a wonderful framework. I have recently
> found this while searching and really liked it.
>
> I am trying to use this for one of my application in which application
> on multiple client nodes will be centrally managed from single server.
> To establish connection between client and server we have two use cases.
>
> 1. First one is to start server initially and then start client by
> providing IP address and port number of server to connect. This looks
> straightforward with Etch and I was able to do that successfully.
> 2. Another case is to server may have started initially or not, but
> start client with no information about server. The client will just
> keep running and listening. Then user will fire discovery from server
> interface by providing range of IP address in the network and then
> server will contact etch IP address and try to establish connection
> with client. This may be giving request to client to make connection
> on blah blah server on blah blah port.
>
> Is it possible to achieve #2 case above by any means in Etch framework
> itself?
>
> Thanks,
> Prashant
Re: Query regarding client discovery
Posted by scott comer <we...@mac.com>.
hi prashant,
two years ago we started defining an etch naming service, there might be
stuff in the wiki or even in the source code about that. that work has
been dormant since then.
we are (at spawnlabs) resurrecting that work with an eye to our own use.
but i would make as much of the code public as possible.
here's the idea, loosely:
normally one opens a client session using a uri such as this:
tcp://host:port?filter=blah
if you then deploy a bunch of clients, then they are pretty well bound
to have trouble when you need to change host, port, or the filters. and
certainly if you decided you wanted to use the tls scheme instead. so,
rather than use the raw uri spec for the connection, what if you use a
uri like this:
etch:my-service-type/my-service-name
and somewhere else could specify a mapping:
my-service-type/my-service-name = tcp://host:port?filter=blah
that mapping could be in a defined local file or resource or in a remote
service. we defined such a remote service
and gave it an api and demonstrated this technique.
the etch scheme, then, selects a TransportFactory which knows how to use
that api to find the requested service uri by using the defined
NameService api.
obvious extension is to allow a query instead of just a name, say based
on service type, locality, etc.
how do you find the NameService itself?
dhcp? system property? broadcast lookup? bonjour? endless possibilities...
best, though, would be to use the defined NameService api and scheme, if
that works for you. if not, let's figure out why not and fix it.
scott out
On 4/14/2011 6:17 AM, Prashant Shewale wrote:
> Hi,
>
> First of all thanks for such a wonderful framework. I have recently
> found this while searching and really liked it.
>
> I am trying to use this for one of my application in which application
> on multiple client nodes will be centrally managed from single server.
> To establish connection between client and server we have two use cases.
>
> 1. First one is to start server initially and then start client by
> providing IP address and port number of server to connect. This looks
> straightforward with Etch and I was able to do that successfully.
> 2. Another case is to server may have started initially or not, but
> start client with no information about server. The client will just
> keep running and listening. Then user will fire discovery from server
> interface by providing range of IP address in the network and then
> server will contact etch IP address and try to establish connection
> with client. This may be giving request to client to make connection
> on blah blah server on blah blah port.
>
> Is it possible to achieve #2 case above by any means in Etch framework
> itself?
>
> Thanks,
> Prashant