Community
Participate
Working Groups
When connecting to a remote system, RSE should be able to detect available services automatically. Details are specified on the Wiki http://wiki.eclipse.org/index.php/DSDP/TM/Autodetect More details to be specified here. See also bug 140320 (autodetect container), and bug 142493.
This also depends on the request to make RSE more service-oriented (bug 150498)
Remote services can be discovered and created dynamically using DNS-SD. Other protocols can be added as extension points.
Can you please update the dependent bugs. I cannot see how this one can be marked "fixed" when the dependent bugs are not all fixed. The two other questions I have with respect to service discovery in RSE 2.0 are: 1. Assume that a service like FTP is advertised by DNS-SD on a host, but FTP is running on a non-standard port. Is there a standard mechanism for discovering it and setting the non-standard port (or other properties that need to be configured) in the subsystem? 2. What about "meta-subsystems" like the Linux Shell Process Service. These do not have a standard service type or transport type, since they re-use any RSE Shell transport. Can such subsystems ever be discovered automatically? Can the Discovery Wizard offer addition of such subsystems to the user? Assume that an ssh or telnet shell connection has been discovered, then the Wizard should allow the user to also add the Linux Shell Processes subsystem if he wants. Perhaps the servicetype for Linux Shell Processes should be serviceType="linux.process.rseshell" ? Should we file a new separate bug for improvements in this area?
(In reply to comment #3) > 1. Assume that a service like FTP is advertised by DNS-SD on a host, but FTP > is running on a non-standard port. Is there a standard mechanism for > discovering it and setting the non-standard port (or other properties that > need to be configured) in the subsystem? The DNS-SD protocol requires some compulsory service information to be transferred. Those compulsory fields are "port" "priority" and "weight". This information, as well as other custom attributes are stored as in the "Discovery" properties of each service. Then, the service discovery wizard configures the discovered services to use the port specified by DNS-SD > 2. What about "meta-subsystems" like the Linux Shell Process Service. These do > not have a standard service type or transport type, since they re-use > any RSE Shell transport. Can such subsystems ever be discovered > automatically? Can the Discovery Wizard offer addition of such subsystems > to the user? Yes, as long as the advertised name and transport matches the serviceType attribute of the plugin (eg "_shellProcess._tcp") > Assume that an ssh or telnet shell connection has been discovered, then the > Wizard should allow the user to also add the Linux Shell Processes subsystem > if he wants. > Perhaps the servicetype for Linux Shell Processes should be > serviceType="linux.process.rseshell" ? I think, in this case the service discovery agent should advertise a dstore.processes service, as "_dstore_processes._tcp" as well as ssh and ftp. So after the wizard you would have a discovered host containing a ftp, ssh and dstore.processes clients. > Should we file a new separate bug for improvements in this area? we could use the autodetect container (bug 140320), as otherwise the information is too spreaded and difficult to follow and comment by the users
(In reply to comment #4) > transferred. Those compulsory fields are "port" "priority" and "weight". This > information, as well as other custom attributes are stored as in the > "Discovery" properties of each service. So, in order to properly take part in Service Discovery, the ftp / daytime / ssh Service (or subsystem) needs to know about a PropertySet named "Discovery" and read a "port" attribute from it? Is this documented somewhere or planned to be documented? > Then, the service discovery wizard configures the discovered services to use > the port specified by DNS-SD How? Using a PropertySet? Where would that be stored? > Yes, as long as the advertised name and transport matches the serviceType > attribute of the plugin (eg "_shellProcess._tcp") But that's the point -- we are not at all bound to tcp here. ANY underlying rse-supported shell can be the transport. The shell itself can use tcp, udp, serial or whatever transport it likes. So I thought that for the meta-service, a correct "transport" identifier is "rseshell". A proper service would be linux_processes, see below. Summing up to serviceType="linux_processes.rseshell" > I think, in this case the service discovery agent should advertise a > dstore.processes service, as "_dstore_processes._tcp" as well as ssh and ftp. But it is neither using dstore nor tcp. It's using the /proc filesystem on a linux box, accessed through any shell (rlogin, telnet, ssh, serial console or whatever). So I would understand "linux_processes.*" since what the agent advertises is the existence of a linux compatible /proc filesystem only, which may be accessed through any transport the user likes. > we could use the autodetect container (bug 140320), as otherwise the > information is too spreaded and difficult to follow and comment by the users Then I prefer keeping the discussion here for now since this is a plan item. The autodetect container should be obsoleted by the plan item.
(In reply to comment #5) > So, in order to properly take part in Service Discovery, the ftp / daytime / ssh > Service (or subsystem) needs to know about a PropertySet named "Discovery" and > read a "port" attribute from it? Is this documented somewhere or planned to be > documented? The setup of the port is automatically done by the wizard. And the "discovered" information is also stored in a propertyset but it doesn't have to be accessed by the service. It only stays there because it's data provided by the discovery agent, and it can be interesting later on. It will be documented, though. > > Then, the service discovery wizard configures the discovered services to use > > the port specified by DNS-SD > How? Using a PropertySet? Where would that be stored? No, it sets the port of the service through the API using org.eclipse.rse.core.subsystems.IConnectorService.setPort(int) > > Yes, as long as the advertised name and transport matches the serviceType > > attribute of the plugin (eg "_shellProcess._tcp") Or "_myService._mytransport", it's up to the discovery agent and to the subsystemconfiguration plugin to provide the same name and transport. > But that's the point -- we are not at all bound to tcp here. ANY underlying > rse-supported shell can be the transport. The shell itself can use tcp, udp, > serial or whatever transport it likes. So I thought that for the meta-service, a > correct "transport" identifier is "rseshell". A proper service would be > linux_processes, see below. Summing up to > serviceType="linux_processes.rseshell" I don't think I got the idea of a meta-service... Do you mean that a service called "linux_processes" is not going to be attached to a list of transports ? At the moment, the list of exisiting services+transports that I can identify in open source is: * "_daytime._tcp" * "_ssh._tcp" * "_sftp._tcp" * "_ftp._tcp" * "_telnet._tcp" * "_telnet._serial" * "_dstore_files._tcp" * "_dstore_shells._tcp" * "_dstore_processes._tcp" Let me know if you identify more or want to change any. > But it is neither using dstore nor tcp. It's using the /proc filesystem on a > linux box, accessed through any shell (rlogin, telnet, ssh, serial console or > whatever). Then, the rlogin, telnet, ssh, serial console or supported services to access the /proc filesystem should be advertised, shouldn't it ? > So I would understand "linux_processes.*" since what the agent > advertises is the existence of a linux compatible /proc filesystem only, which > may be accessed through any transport the user likes. I think is better is the discovery agent lists the transports, instead of using *, something like "_linux_processes._tcp;_linux_processes._serial"
(In reply to comment #6) > It only stays there because it's data provided by the discovery agent, and it > can be interesting later on. It will be documented, though. Ok, sounds good. > No, it sets the port of the service through the API using > org.eclipse.rse.core.subsystems.IConnectorService.setPort(int) Ah, now I see. Excellent. > I don't think I got the idea of a meta-service... > Do you mean that a service called "linux_processes" is not going to be > attached to a list of transports ? Yes. Since we have a generic shell API in RSE, it can use any shell subsystem that an extender contributes. Basically, it is a service which uses another service as transport (instead of a plain standard transport). Looks like we simply don't have such a concept of stacked services in Service Discovery yet; that's OK for me. We might want to add it at some point in the future. Until we do, I'm OK with allowing the user to manually add such subsystems. > * "_dstore_files._tcp" > * "_dstore_shells._tcp" > * "_dstore_processes._tcp" Your list looks good. In the case of dstore, what is the meaning of the underscore? In classic C programs, identifiers starting with underscore are reserved by the compiler so users must not use them. Applying the same to discovery identifiers, since we define dstore ourselves, I'd expect it to not use an underscore. Is there some guideline when the underscore should be there? The other thing is, that dstore is really also some kind of a transport, with files/shells/processes being a service on top of that transport. Would an id like * "rsefiles.dstore._tcp" * "rseshell.dstore._tcp" * "rseprocesses.dstore.tcp" make sense? > Then, the rlogin, telnet, ssh, serial console or supported services to access > the /proc filesystem should be advertised, shouldn't it ? Hm, I'm afraid that this would lead to an explosion of services. I agree, though, that the various kinds of shells should be advertised: _rlogin._tcp, _telnet._tcp, _ssh._tcp, _telnet._serial Based on this we can have RSE shell subsystems bound to them. At some point in the future we might want to sort out how the stacked process service on top of any rse shell can be advertised and configured. Doesn't DNS-SD allow for other properties of the host, in addition to the advertised services? Knowing that the host has properties like os="Linux" might suffice.
(In reply to comment #7) > Your list looks good. In the case of dstore, what is the meaning of the > underscore? In classic C programs, identifiers starting with underscore are > reserved by the compiler so users must not use them. Applying the same to > discovery identifiers, since we define dstore ourselves, I'd expect it to not > use an underscore. Is there some guideline when the underscore should be there? It follows the DNS SRV syntax (http://en.wikipedia.org/wiki/SRV_record) > The other thing is, that dstore is really also some kind of a transport, with > files/shells/processes being a service on top of that transport. Would an id > like > * "rsefiles.dstore._tcp" > * "rseshell.dstore._tcp" > * "rseprocesses.dstore.tcp" > make sense? I think it makes more sense, and is more integrated with the rest of services: * "_rsefiles_dstore._tcp" * "_rseshell_dstore._tcp" * "_rseprocesses_dstore._tcp" As, the dstore server can be advertised in different ways to different clients. This approach is what I use to advertise different services to RSE that in fact are run by the same server on the embedded device. > > Then, the rlogin, telnet, ssh, serial console or supported services to access > > the /proc filesystem should be advertised, shouldn't it ? > Hm, I'm afraid that this would lead to an explosion of services. I agree, > though, that the various kinds of shells should be advertised: > _rlogin._tcp, _telnet._tcp, _ssh._tcp, _telnet._serial Using * as a transport could introduce issues as displaying as "supported" a service that is not. It could happen because of the introduction of a new non-supported transport to the remote server. > Doesn't DNS-SD allow for other > properties of the host, in addition to the advertised services? Knowing that the > host has properties like > os="Linux" > might suffice. Yes, any pair attribute/value can be passed describing each service.
(In reply to comment #8) > It follows the DNS SRV syntax (http://en.wikipedia.org/wiki/SRV_record) Hm, from this article I cannot see why the underscore is there, but I'll just accept it for now. The other thing I found is that according to http://www.dns-sd.org/ServiceTypes.html our sftp client should be * "_sftp-ssh._tcp" Following this example, and taking into account that there is a 14 characters maximum limitation on the service type, we should do * "_dstore-files._tcp" * "_dstore-shell._tcp" * "_dstore-proc._tcp" I'm fine with the rest.
Consider this done for TM 2.0M7, especially the work on bug #173468 was important. For the future, more improvements will be made especially for making RSE more service-oriented and improving the UI to access those services (bug #176490, bug #142493).
[target cleanup] 2.0 M7 was the original target milestone for this bug
