Hi Peter Thanks for your valuable reply.Could you elaborate more on serverHost string. I found serverHost variable on phoenix.policy file. Currently I am just using a simple reggie(Jrmp-reggie) in order to register of my proxy. And, I started it inside localnetwork to which I could connect from outside network by using port forwarding. However, as I stated in my previous email, once it got the proxy, it is assigned by local IP and could not download the remaining codes of the services. I would like to set the dns name string instead of InetAddress. Could you elaborate more about it so that I can configure more properly. I think I may have missed that. RegardsBishnu
Bishnu Prasad Gautam > Date: Wed, 6 Jul 2016 21:01:53 +1000 > From: j...@zeus.net.au > Subject: Re: Lotj - languages other than java > To: dev@river.apache.org > > Hi Bishnu, > > The serverHost is a dns name string argument that you use in your > configuration when choosing & creating an instance of a ServerEndpoint, if > this is null, it defaults to the InetAddress. > > Endpoints support multiple ip addresses, the first successful address is used > during dns resolution . > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Bishnu Gautam <bishn...@hotmail.com> > Sent: 06/07/2016 08:11:49 pm > To: dev@river.apache.org <dev@river.apache.org> > Subject: RE: Lotj - languages other than java > > Thanks Peter For the introduction of new implementation. I will go through > it.Between, here is the scenario that I often faced and I am pretty sure that > most of the users have faced is this: > 1. It is possible to invoke lookup service from the internet and even getting > the registrar is possible. In fact I was able to find the lookup server > behind the NAT and firewall.2. Once I get the registrar the service > registered in this registrar seems to have local IP3. Therefore the client > from the internet is not able to set up the connection by using the proxy as > it gave you local IP. > This problem occurred because the lookup service was running in private IP > and not assigned by global IP directly into its interface. If the > lookupserver is directly assigned by global IP, there would be no problem to > publicize the current lookup server. However, in our case and most of the > servers inside the networks are not directly assigned global IP but are > assigned in a gateway machine having NAT facility due to security reasons. > The static NAT and some other techniques are applied in order to access the > services through outside network and it is quite possible because they are > port forwarded and synchronize the filtering rules properly. However port > forwarding technique alone is not helpful in the case of river. Because > registrar (kept inside firewall and NAT) seems to have the proxy service > which has local IP whenever it is downloaded to the client machine. In the > first connection, it is possible to locate the lookuplocater by using port > forwarding technique however once it is located it returns the proxy services > having local IP. This scenario is becoming a possible design flaw in River > and limiting the users of this technology.I would like to suggest you to > assign domain name in any case rather than assigning IP in its proxy. Because > if you assign domain name rather than IP, the lookup can be made without > considering whether a call from local network or global network. Because when > lookup is done from within a network, dns will return local IP and it will > return global IP whenever it is done from outside network. In this case, > there will be no problem once it is accessed by port forwarding technique > too. So, we should rely upon DNS. So, it is quite possible that the codebase > is assigning the local IP to its proxy service. So, need to tweak this > scenario too. This seems lookup overhead but it seems to be the only solution > to overcome NAT and Firewall locking to the River solution I think that this > issue can be solved by you guys with minimal effort. Let me know if you could > tweak the code of registrar as explained above. This will certainly enable a > huge potential to this technology. Please correct me if something is missing > here. > RegardsBishnu > > > Bishnu Prasad Gautam > > > > Date: Wed, 6 Jul 2016 16:25:12 +1000 > > From: j...@zeus.net.au > > To: dev@river.apache.org > > Subject: Re: Lotj - languages other than java > > > > Thanks Bishnu, > > > > I plan to set up a public lookup service later this year, or early next > > over IPv6 (dependant on me completing the work on github), there's a > > beta release of the code available you can experiment with. > > > > It will be possible to discover this lookup service dynamically using > > the global IPv6 multicast address FF0X::155 for Jini-announcement. > > > > For DOS reasons, Jini-request will only be available for local network use. > > > > http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > > > > > > Before I could make a lookup service publicly available, I've had to do > > a lot of work on addressing security issues: > > > > 1. Serialization atomic input validation. > > 2. Two new default methods in ServiceRegistrar so that clients can > > authenticate services, prior to deserializing their proxy's, > > Entry's and downloading or provisioning codebases. > > 3. New discovery providers with updated cryptographic hash functions > > for secure discovery and added input validation for > > deserialization of registrar proxy. > > 4. Dynamic granting of DownloadPermission and > > DeserializationPermission (similar to deserialization > > whitelisting) to authenticated services (to allow their proxy to > > be deserialized / downloaded). > > 5. Allow listing of Permissions within jar files, for smart proxy's > > and have these granted dynamically if service authentication > > succeeds. > > 6. Update encryption cyphers and invocation constraints. > > > > Existing River / Jini deployments will not be able to contact this > > lookup service, in the event they could, they cannot satisfy the > > ConfidentialityStrength invocation constraints either unfortunately. On > > local networks security could be relaxed sufficiently to allow > > compatibility with an existing River deployment, but public lookup > > services should not make that compromise. > > > > The Serial form of objects are compatible with River. > > > > This is all beta, new API may change if adopted by River. > > > > Regards, > > > > Peter. > > > > On 6/07/2016 3:36 PM, Bishnu Gautam wrote: > > > Thanks Peter for your detail explanation regarding River on Internet.I > > > will go through it. By the way do you have any publicly available Lookup > > > service to which I can register my proxy service and this proxy service > > > will refer my web server by which I could download my rest of the actual > > > service codes (fully implemented) from the publicly available web > > > server(in which my service codes are located). In fact I am trying to > > > avail Lookup Server publicly so that the user could register their proxy > > > services in my lookup server.Let me know if anybody already made it > > > available for public use. Once we are able to do it we do not need to > > > rely upon REST too and also do not need to tackle with NATing and packet > > > filtering issues. I am looking whether there are any workable publicly > > > available lookup services to which I can register my proxy. > > > RegardsBishnu > > > > > > > > > Bishnu Prasad Gautam > > > > > > > > >> Date: Tue, 5 Jul 2016 17:46:14 +1000 > > >> From: j...@zeus.net.au > > >> To: dev@river.apache.org > > >> Subject: Re: Lotj - languages other than java > > >> > > >> Thanks Bishnu, > > >> > > >> Mark Brouwer originally pointed out many years ago, that while jini had > > >> https jeri endpoints, there was no support to perform unicast discover > > >> over https in LookupLocator discovery. > > >> > > >> I have implemented that. > > >> > > >> Now, you can have any number of publicly available lookup services, and > > >> contact them using https unicast with LookupLocator, > > >> ConstrainableLookupLocator and LookupLocatorDiscovery. DNS-SD is an > > >> obvious substitute for multicast discovery for clients behind firewalls, > > >> but it hasn't been implemented yet. > > >> > > >> With public lookup services, even when not discoverable with multicast > > >> discovery (because your clients are behind firewalls), can register with > > >> each other, using multicast discovery, allowing clients behind firewalls > > >> to find others, so they only need to know a few permanent registrars to > > >> find others, when they don't have access to multicast discovery. > > >> > > >> Non public service clients (behind firewalls or NAT) can locate public > > >> services. Non public clients can listen behind NAT and firewalls, when > > >> they register a listener with a lookup service, they will be notified of > > >> new service registrations, because https jeri endpoints will keep the > > >> connection (ports) open between a lookup service and clients behind > > >> firewalls. > > >> > > >> So lets say for example, you have an embedded client behind a firewall, > > >> which is also a master for an IoT wireless local network and there are > > >> several devices that will send a video stream or other data, then for > > >> instance a public consumer service, could register with a lookup service > > >> where the embedded client was listening, then be contacted and > > >> authenticated by the embedded client and access a service directly from > > >> the client to receive live data streams from that wireless network, this > > >> may then republish the data accumulated from multiple such embedded > > >> clients via a web site. Clients behind NAT must initiate contact, only > > >> then can they be contacted. > > >> > > >> JERI multiplexes, so you can have 127 active service connections over > > >> one connection between two nodes. > > >> > > >> LetsEncrypt.org is a free certificate authority than can be utilised for > > >> https jeri endpoints. LetsEncrypt.org doesn't provide code > > >> certificates, so they can't be used for signing jar files. > > >> > > >> To avoid the expense of CA signed codebase certificates, https discovery > > >> automatically grants DownloadPermission and DeserializationPermission > > >> (which is required to allow proxy deserialization over a https jeri > > >> endpoint with an InputValidation constraint), to an anoymous code signer > > >> certificate and uri exchanged during the discovery process, but only if > > >> authentication is successful. The codebase jar file can also contain > > >> the permissions it requires, so that these can be granted dynamically by > > >> the client during proxy preparation. > > >> > > >> In addition https jeri endpoint encryption cyphers have all been updated > > >> to modern secure cyphers and support for insecure cyphers has been > > >> removed. > > >> > > >> Default methods have been added to ServiceRegistrar, to allow the client > > >> to authenticate services prior to retrieving proxy's and Entry's. > > >> ProxyTrust verfiiers are no longer necessary as the proxy is obtained > > >> directly from the service after authentication, rather than via a third > > >> party. The proxy is already trusted. > > >> > > >> https://pfirmstone.github.io/river-internet/ > > >> > > >> I hope to get this accepted by River at some point, I figure that > > >> creating a demonstration will assist the understanding process for other > > >> developers, as I wasn't able to communicate effectively enough to avoid > > >> strong resistance and criticism when I originally proposed it. > > >> > > >> Regards, > > >> > > >> Peter. > > >> > > >> > > >> On 5/07/2016 1:33 PM, Bishnu Gautam wrote: > > >>> Hi Peter > > >>> It is great that you pointed out lookup locator issue in firewall and > > >>> its potential solution. It would be great to see the developments in > > >>> River in which they really focus to have lookup discovery beyond the > > >>> firewall without requiring port forward and other demanding packet > > >>> filtering techniques. Once this obstacle in River is crossed, I am > > >>> pretty sure that there will be new paradigm shift in IoT or ICT > > >>> technology. This technology has a tremendous potential. However, I > > >>> never understand why River community never try to bring this issue on > > >>> the first place. River in Internet would be the most wonderful > > >>> solutions for millions of users around the world. Please think, discuss > > >>> and try to work on it. It would be a great news for us. > > >>> RegardsBishnu > > >>> > > >>> > > >>> Bishnu Prasad Gautam > > >>> > > >>> > > >>>> Date: Mon, 4 Jul 2016 18:37:25 +1000 > > >>>> From: j...@zeus.net.au > > >>>> Subject: Re: Lotj - languages other than java > > >>>> To: dev@river.apache.org > > >>>> CC: si...@qcg.nl > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Sim, > > >>>> > > >>>> I'd like to see the project return to the days where we had a number > > >>>> of active committers working together on the same goals. > > >>>> > > >>>> I've got a project on github, where I've continued work that was > > >>>> controversial, I'd like to bring this work back to the project if > > >>>> possible. It has some minor breaking changes, but if backward > > >>>> compatibility was essential, it could be accommodated. > > >>>> > > >>>> Changes: > > >>>> * New secure discovery providers, including https among others, > > >>>> including added https protocol support for LookupLocator. However > > >>>> since firewalls may not allow ipv6 multicast packets through, DNS-SD > > >>>> would be useful. > > >>>> * IPv6 Discovery, global and local groups. > > >>>> * Discovery V2 support added to LookupLocator's getRegistrar method. > > >>>> * Updated encryption ciphers, removal of insecure ones. > > >>>> * Deprecation of ProxyTrust et al. > > >>>> * New default methods added to ServiceRegistrar to allow establising > > >>>> trust with a service, prior to obtaining a service proxy, or Entry's > > >>>> (works with both maven codebase provisioning and traditional codebase > > >>>> downloads). > > >>>> * Input validation for untrusted serial data. > > >>>> * META-INF/permissions.perm files list permissions required by > > >>>> codebase, accessible from ClassLoader using mixin interface. > > >>>> > > >>>> I recall you had a need for a SocketFactory in LookupLocator, at that > > >>>> time LookupLocator only used discovery v1, which was deprecated, I'd > > >>>> like to include a way to enable SocketFactory support in discovery V2. > > >>>> Note that LookupLocator isn't serialized during discovery. > > >>>> > > >>>> While the River codebase was a little difficult to understand at > > >>>> first, I find it's quite easy to work with now. > > >>>> > > >>>> While I'm a critic of Rivers flaws, addressing th em is straight > > >>>> forward, the greatest challenge is convincing everyone that flaws > > >>>> exist, or that they need addressing, there's still plenty of good > > >>>> stuff left worth saving > > >>>> > > >>>> Regards, > > >>>> > > >>>> Peter. > > >>>> > > >>>> > > >>>> Sent from my Samsung device. > > >>>> > > >>>> Include original message > > >>>> ---- Original message ---- > > >>>> From: Peter<j...@zeus.net.au> > > >>>> Sent: 01/07/2016 04:35:16 pm > > >>>> To: dev@river.apache.org<d...@riverapache.org> > > >>>> Subject: Re: Lotj - languages other than java > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Thanks Sim, > > >>>> > > >>>> These are all good questions we need to consider. > > >>>> > > >>>> I like the model of micro services where each service is responsible > > >>>> for implementing its own back end persistence and state. Do you > > >>>> consider a microservice to be web based? > > >>>> > > >>>> I have an implementation of discovery using multicast ipv6. However > > >>>> for firewalls with limited open ports such as https over ipv6, we have > > >>>> JERI https endpoints, but no discovery, DNS-SD is a good discovery > > >>>> alternative waiting to be implemented. > > >>>> > > >>>> For my own environment I will be adopting ipv6 , the global address > > >>>> space and autoconfiguration solve many problems that users experience > > >>>> with ipv4 today. > > >>>> > > >>>> I admit the locked down api caused me frustration, but I think it's > > >>>> clear now that we need a process for managing api evolution. > > >>>> > > >>>> Complexity - The proxy preparation api tries to determine trust after > > >>>> downloading untrusted code and deserialization of unverified data. As > > >>>> gadget attacks demonstrate, too little too late at great complexity. > > >>>> This was an attempt to bolt security onto the existing lookup service. > > >>>> > > >>>> JERI is good, method constraints are good, proxy trust is obsolete. > > >>>> River's current ssl and https JERI endpoints need to be brought up to > > >>>> date as they're no longer secure. I've already done this work > > >>>> externally, it can be donated when appropriate for the project. > > >>>> > > >>>> If we address security issues, we can provide a secure alternative to > > >>>> RMI Oracle has chosen 'whack a mole' security for Serialization, > > >>>> rather than address some fundamental design flaws with > > >>>> ObjectInputStream, for this reason, authentication of the source must > > >>>> occur prior to accepting serial data. Despite common belief, white > > >>>> listing isn't a completely secure solution and adds conplexity as it's > > >>>> too fine grained. > > >>>> > > >>>> For multi language support, this would limit the type system, but > > >>>> then, there's a lot that can be done with strings, primitive types and > > >>>> byte arrays. This doesn't have to limit java service types, I think > > >>>> language support should be something determined during lookup, so we > > >>>> don't limit the type systems of more powerful languages to primitives. > > >>>> > > >>>> Looking at most Entry's used for lookup, most fields are strings and > > >>>> integers. If you look at the way lookup searches are implemented, an > > >>>> entry is represented by a string name and each field is a tuple name > > >>>> value pair. > > >>>> > > >>>> I think a ground up redesign of the lookup service, would address > > >>>> language compatibility as well as complexity and security. > > >>>> > > >>>> In other words, recognise the need for a lookup& registration > > >>>> protocol, as well as discovery, after that, the service& client > > >>>> should be able to negotiate whatever rpc protocol they have in common > > >>>> and to do that, we'll also need a connection negotiation protocol. We > > >>>> could write specifications for these protocols. This way we could > > >>>> allow any language/ platform to register and provide services. The > > >>>> code for lookup would not be downloaded as Reggie is now, it would be > > >>>> protocol, rather than proxy based. This would also fit well with IoT. > > >>>> > > >>>> Meanwhile we can still support existing java based services. > > >>>> > > >>>> Thoughts? > > >>>> > > >>>> Peter. > > >>>> > > >>>> Sent from my Samsung device. > > >>>> > > >>>> Include original message > > >>>> ---- Original message ---- > > >>>> From: Simon IJskes - QCG<si...@qcg.nl> > > >>>> Sent: 30/06/2016 06:22:30 pm > > >>>> To: dev@river.apache.org > > >>>> Subject: Re: Lotj - languages other than java > > >>>> > > >>>> If you solve the 'barrier' of the service discovery, do you also want > > >>>> to > > >>>> provide universal access to the java services in the form of > > >>>> microservices? > > >>>> > > >>>> It is doable to take any 'more used' service discovery solution and > > >>>> use > > >>>> this as the river discovery. To introduce a level of abstraction with > > >>>> the same primitives as the current river discovery mechanism offers. > > >>>> > > >>>> River would then have adapted a more common discovery mechanism. > > >>>> > > >>>> Next thing that we should decide, is how far do we go into > > >>>> universality. > > >>>> I see univeral type systems, different serialisation plugins on the > > >>>> horizon. > > >>>> > > >>>> The biggest showstopper for me was the API compatibility. In order to > > >>>> make any progress we need a more agile process for modifing the API > > >>>> > > >>>> If we leave compatibility behind us, we could ask our selfs, what > > >>>> benefit are we providing for the users? What can we introduce that > > >>>> does > > >>>> not duplicate what is already in the market For a java developer, i > > >>>> think there is no need to convince, they can see benefits in just > > >>>> having > > >>>> a java API to program against. We need to think about the environment > > >>>> where java receives a lot of 'non-love', how we can create a 'whow, > > >>>> java > > >>>> isn't all that bad, look at that easy solution' experience. > > >>>> > > >>>> I think that river lost the spot it could have, as a java only > > >>>> solution > > >>>> to JSON, XMLRPC, SOAP, etc libraries for java From a helicopter view, > > >>>> what does it do? Whe provide secure RPC, with discovery and scaling. > > >>>> And > > >>>> we make it hard to use. > > >>>> > > >>>> G. Simon > > >>>> > > >>>> > > >>>> On 30-06-16 05:37, Peter wrote: > > >>>>> Currently with River, you need java to participate. Other languages > > >>>>> can provide services, but you need a jvm to participate. > > >>>>> > > >>>>> Most of discovery is language agnostic, so any language can > > >>>>> participate in discovery. > > >>>>> > > >>>>> The major limitation for other languages is the lookup service. > > >>>>> Security issues and complexity also relate to the lookup service. > > >>>>> > > >>>>> My thoughts are that a lookup service that performs search and > > >>>>> registration, but provides a language independent and secure means > > >>>>> of contacting service providers would be beneficial. > > >>>>> > > >>>>> Anyone interested in discussing further? > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Peter. > > >>>>> > > >>>>> > > >>>>> Sent from my Samsung device. > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > > > > >
