You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Bishnu Gautam <bi...@hotmail.com> on 2012/09/02 02:56:05 UTC

RE: WELCOME to dev@river.apache.org

Hello River Team
It seems that Jini is getting its pace in terms of River. This is good indication and I think that River has great potential if we can build some application that can interact over Internet.I am planning to do a research work whether we can make an application of River that can interact over internet as I found there are some issues of firewall etc. Would you let me know, whether the River team has plan of bringing River on the Internet ? 

Bishnu Prasad Gautam 

> Date: Sun, 2 Sep 2012 00:48:45 +0000
> From: dev-help@river.apache.org
> To: bishnu35@hotmail.com
> Subject: WELCOME to dev@river.apache.org
> 
> Hi! This is the ezmlm program. I'm managing the
> dev@river.apache.org mailing list.
> 
> I'm working for my owner, who can be reached
> at dev-owner@river.apache.org.
> 
> Acknowledgment: I have added the address
> 
>    bishnu35@hotmail.com
> 
> to the dev mailing list.
> 
> Welcome to dev@river.apache.org!
> 
> Please save this message so that you know the address you are
> subscribed under, in case you later want to unsubscribe or change your
> subscription address.
> 
> 
> --- Administrative commands for the dev list ---
> 
> I can handle administrative requests automatically. Please
> do not send them to the list address! Instead, send
> your message to the correct command address:
> 
> To subscribe to the list, send a message to:
>    <de...@river.apache.org>
> 
> To remove your address from the list, send a message to:
>    <de...@river.apache.org>
> 
> Send mail to the following for info and FAQ for this list:
>    <de...@river.apache.org>
>    <de...@river.apache.org>
> 
> Similar addresses exist for the digest list:
>    <de...@river.apache.org>
>    <de...@river.apache.org>
> 
> To get messages 123 through 145 (a maximum of 100 per request), mail:
>    <de...@river.apache.org>
> 
> To get an index with subject and author for messages 123-456 , mail:
>    <de...@river.apache.org>
> 
> They are always returned as sets of 100, max 2000 per request,
> so you'll actually get 100-499.
> 
> To receive all messages with the same subject as message 12345,
> send a short message to:
>    <de...@river.apache.org>
> 
> The messages should contain one line or word of text to avoid being
> treated as sp@m, but I will ignore their content.
> Only the ADDRESS you send to is important.
> 
> You can start a subscription for an alternate address,
> for example "john@host.domain", just add a hyphen and your
> address (with '=' instead of '@') after the command word:
> <de...@river.apache.org>
> 
> To stop subscription for this address, mail:
> <de...@river.apache.org>
> 
> In both cases, I'll send a confirmation message to that address. When
> you receive it, simply reply to it to complete your subscription.
> 
> If despite following these instructions, you do not get the
> desired results, please contact my owner at
> dev-owner@river.apache.org. Please be patient, my owner is a
> lot slower than I am ;-)
> 
> --- Enclosed is a copy of the request I received.
> 
> Return-Path: <bi...@hotmail.com>
> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
> Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:45 +0000
> X-ASF-Spam-Status: No, hits=2.4 required=5.0
> 	tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
> X-Spam-Check-By: apache.org
> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.com designates 65.55.90.77 as permitted sender)
> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com) (65.55.90.77)
>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:36 +0000
> Received: from SNT145-W136 ([65.55.90.71]) by snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
> 	 Sat, 1 Sep 2012 17:48:15 -0700
> Message-ID: <SN...@phx.gbl>
> Content-Type: multipart/alternative;
> 	boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
> X-Originating-IP: [122.18.73.194]
> From: Bishnu Gautam <bi...@hotmail.com>
> To:
> 	<de...@river.apache.org>
> Subject: RE: confirm subscribe to dev@river.apache.org
> Date: Sun, 2 Sep 2012 00:48:15 +0000
> Importance: Normal
> In-Reply-To: <13...@river.apache.org>
> References: <13...@river.apache.org>
> MIME-Version: 1.0
> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC) FILETIME=[A3545700:01CD88A4]
> X-Virus-Checked: Checked by ClamAV on apache.org
> 
 		 	   		  

Re: WELCOME to dev@river.apache.org

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 02-09-12 02:56, Bishnu Gautam wrote:
>
> Hello River Team It seems that Jini is getting its pace in terms of
> River. This is good indication and I think that River has great
> potential if we can build some application that can interact over
> Internet.I am planning to do a research work whether we can make an
> application of River that can interact over internet as I found there
> are some issues of firewall etc. Would you let me know, whether the
> River team has plan of bringing River on the Internet ?

Very good! I would say, go for it! I've tried two approaches, 
river-mekong which is a client pulling data from internet reachable 
rendezvous, and currently have in production a http based tcp vpn. But 
these have a few problems:

- There is no optimization for connecting nodes when there is a direct 
connection possible.
- I dont like the solution to use a subrange from IPv6 adressing range 
to distinguish between direct connections and vpn ones.
- There is no solution for registries on every node.

I hope that if you create code for your project, you are willing to 
donate the code to the river project.

If you have any textual contributions, ideas, etc. to make, i'm happy to 
add them to the ROTI page:

http://river.apache.org/discussion-internet.html




-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: WELCOME to dev@river.apache.org

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 04-09-12 02:26, Bishnu Gautam wrote:
> Yes, I was thinking of DNS-SRV
> discovery. Also, UDT is better than TCP. I am very interested to use
> Java UDT and totally agree to apply this protocol. That will
> efficiently work I think. I am building an application that transfer
> all bundled JPanel wraped jini/river services to client sides. I am
> able to execute it in muliti-Lan environment.

What solution do you use, to have 2 lan's with the same network address 
(for example 10.0.0/24) sharing services? In other words, what do you 
use to identify the ServerEndpoint?

Gr. Simon

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: WELCOME to dev@river.apache.org

Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Bishnu,

Sorry for the slow reply, River is maintained by volunteers, we don't 
have as much time as we'd like.  Your service browser is interesting.

There are significant challenges with security, River (Jini) has 
constraints, which allow clients and services to require integrity, 
confidentiality and minimum server or client principals.  You may find 
constraints very useful, these could be supported in your browsers 
security settings.

JERI has superceded RMI in Jini, it's the standard for exporting service 
objects and allows an administrator to select from pluggable Exporters 
that use different protocols, including RMI, IIOP, TLS etc.  JERI is 
required for constraints.

During object serialization there is a window of time where objects are 
created and class loading occurs, prior to a ProtectionDomain 
representing them being pushed onto the execution stack, allowing an 
attacker to take advantage of privileges the current execution stack 
has, this is the mechanism for java deserialisation privilege escalation 
attacks reported recently by popular media.  To avoid this 
vulnerability, permissions must be minimised during deserialisation.  

JAAS in its standard implementation, injects Principals into all 
ProtectionDomain on the call stack (which must have sufficient privilege 
for it to occur). ProtectionDomains added to the stack after login and 
Subject.doAs, are not injected, but may be subject to deserialisation 
attacks if and when local code is privileged.  A user login adds 
permission to existing ProtectionDomains, which may all be privileged in 
any case.  I've proposed for distributed environments that this 
behaviour be changed so a ProtectionDomain representing the Subject be 
pushed onto the stack instead, allowing a user to have a different alias 
for browsing untrusted networks, where the user has restricted 
permission to prevent deserialisation privilege escallation attacks on 
client or server jvm's, even when the jvm or application code would 
otherwise be vulnerable.  This could be supported as a list of 
permissions the user has selected for the alias on clients, or by being 
granted a particular principal on servers.  This would greatly simplify 
configuring java permissions.

Deserialisation is still subject to denial of service (out of memory 
error or stack overflow), however this is only of inconvenience value, 
the jvm can be easily killed and restarted.

Trust in a community is based on identity and observed behaviour.

SPKI has an interesting authorisation delegation model, allowing users 
to remain anonymous while avoiding the need for Certificate 
Authorities.  An example use case: a company delegates authority to 
access external resources to its employees with short term tickets; 
certificates that expire daily.  A company or household may hold a 
contract with a supplier for a resource, this may expire on monthly or 
annual contract terms, during login, resources may be allocated on a 
daily basis by creating a certificate chain that delegates permission, 
every time a user logs in.

org.apache.river.api.security.PermissionGrant is a stateless abstract 
class (originally designed as an interface, enforcing security was 
complex, so an abstract class was chosen instead) that would also allow 
standard java Permissions to be granted and expire.  There is a 
DelegatePermission framework (implementation to be distributed 
separately) and caching DelegateSecurityManager that for example, 
enables Li Gong's method guard pattern to be applied to existing Socket 
implementations using a SocketFactory wrapper.

Which reminds me; I need to create a directory on svn for the delegates 
implementation.

These things are low level, what is needed is a simplifying upper layer 
that makes using services in the service browser simple and secure.

To achieve goals you've set in the paper, there's plenty of work left to do.

Best Regards,

Peter.


Bishnu Gautam wrote:
> Hi
> No, I am not using ServiceUI, instead, I have written myself that exports the wrapped services to the client. We can still export the very light weight browser as jini service too. In that way, we can still make our jini services that can run in client machine. I am calling this browser as Universal Browser.  I have written a paper about this scenario more in detail at following paper:
> http://www.iaeng.org/publication/IMECS2010/IMECS2010_pp638-643.pdf 
> You may find number of services running in the browser including web browser. Yes, this is the right time how we can make good service interface that can be used by client at end.
> RegardsBishnu
>
>
> Bishnu Prasad Gautam
>
>
>   
>> Date: Tue, 4 Sep 2012 08:12:24 +0100
>> Subject: Re: WELCOME to dev@river.apache.org
>> From: dan.creswell@gmail.com
>> To: dev@river.apache.org
>>
>> Can you say a little more about the JPanel wrapping? Are you making use of
>> ServiceUI or custom generating something or ?
>>
>> The reason I'm asking is because for client-side exposure of graphical
>> material, a browser is a good place to go especially with the arrival of
>> HTML5. In fact, perhaps it's time we re-evaluated ServiceUI...
>>
>> On 4 September 2012 01:26, Bishnu Gautam <bi...@hotmail.com> wrote:
>>
>>     
>>> Hi Peter and Simon
>>> Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is
>>> better than TCP. I am very interested to use Java UDT and totally agree to
>>> apply this protocol. That will efficiently work I think. I am building an
>>> application that transfer all bundled JPanel wraped jini/river services to
>>> client sides. I am able to execute it in muliti-Lan environment. I will
>>> donate this code to river community. My next phase is to implement it to
>>> execute in internet. If you guys have already implemented some of it, lets
>>> share the codes or lets discuss so that we can bring river project as one
>>> of the demanding solution not only in distributed environment but also for
>>> the cloud community. I think this is the right time for jini/river
>>> community to come into the business or into the cloud.
>>> RegardsBishnu
>>>
>>>
>>>
>>>
>>> Bishnu Prasad Gautam
>>>
>>>
>>>       
>>>> Date: Mon, 3 Sep 2012 18:12:55 +1000
>>>> From: jini@zeus.net.au
>>>> To: dev@river.apache.org
>>>> Subject: Re: WELCOME to dev@river.apache.org
>>>>
>>>> Thanks Bishnu, welcome to River!
>>>>
>>>> I've had some plans with regard to internet based services, not much
>>>> implemented I'm afraid, time constraints...
>>>>
>>>>    1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
>>>>       internet based service registrars (lookup service).
>>>>    2. DNS-SRV Discovery, to use in place of multicast discovery, this
>>>>       (not yet implemented) discovers the location of lookup services,
>>>>       to be used in Unicast Discovery.
>>>>    3. Java UDT Sockets - not yet implemented, this is basically Data
>>>>       over UDP, which is easier to get through firewalls than TCP.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Bishnu Gautam wrote:
>>>>         
>>>>> Hello River Team
>>>>> It seems that Jini is getting its pace in terms of River. This is good
>>>>>           
>>> indication and I think that River has great potential if we can build some
>>> application that can interact over Internet.I am planning to do a research
>>> work whether we can make an application of River that can interact over
>>> internet as I found there are some issues of firewall etc. Would you let me
>>> know, whether the River team has plan of bringing River on the Internet ?
>>>       
>>>>> Bishnu Prasad Gautam
>>>>>
>>>>>
>>>>>           
>>>>>> Date: Sun, 2 Sep 2012 00:48:45 +0000
>>>>>> From: dev-help@river.apache.org
>>>>>> To: bishnu35@hotmail.com
>>>>>> Subject: WELCOME to dev@river.apache.org
>>>>>>
>>>>>> Hi! This is the ezmlm program. I'm managing the
>>>>>> dev@river.apache.org mailing list.
>>>>>>
>>>>>> I'm working for my owner, who can be reached
>>>>>> at dev-owner@river.apache.org.
>>>>>>
>>>>>> Acknowledgment: I have added the address
>>>>>>
>>>>>>    bishnu35@hotmail.com
>>>>>>
>>>>>> to the dev mailing list.
>>>>>>
>>>>>> Welcome to dev@river.apache.org!
>>>>>>
>>>>>> Please save this message so that you know the address you are
>>>>>> subscribed under, in case you later want to unsubscribe or change your
>>>>>> subscription address.
>>>>>>
>>>>>>
>>>>>> --- Administrative commands for the dev list ---
>>>>>>
>>>>>> I can handle administrative requests automatically. Please
>>>>>> do not send them to the list address! Instead, send
>>>>>> your message to the correct command address:
>>>>>>
>>>>>> To subscribe to the list, send a message to:
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> To remove your address from the list, send a message to:
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> Send mail to the following for info and FAQ for this list:
>>>>>>    <de...@river.apache.org>
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> Similar addresses exist for the digest list:
>>>>>>    <de...@river.apache.org>
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> To get messages 123 through 145 (a maximum of 100 per request), mail:
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> To get an index with subject and author for messages 123-456 , mail:
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> They are always returned as sets of 100, max 2000 per request,
>>>>>> so you'll actually get 100-499.
>>>>>>
>>>>>> To receive all messages with the same subject as message 12345,
>>>>>> send a short message to:
>>>>>>    <de...@river.apache.org>
>>>>>>
>>>>>> The messages should contain one line or word of text to avoid being
>>>>>> treated as sp@m, but I will ignore their content.
>>>>>> Only the ADDRESS you send to is important.
>>>>>>
>>>>>> You can start a subscription for an alternate address,
>>>>>> for example "john@host.domain", just add a hyphen and your
>>>>>> address (with '=' instead of '@') after the command word:
>>>>>> <de...@river.apache.org>
>>>>>>
>>>>>> To stop subscription for this address, mail:
>>>>>> <de...@river.apache.org>
>>>>>>
>>>>>> In both cases, I'll send a confirmation message to that address. When
>>>>>> you receive it, simply reply to it to complete your subscription.
>>>>>>
>>>>>> If despite following these instructions, you do not get the
>>>>>> desired results, please contact my owner at
>>>>>> dev-owner@river.apache.org. Please be patient, my owner is a
>>>>>> lot slower than I am ;-)
>>>>>>
>>>>>> --- Enclosed is a copy of the request I received.
>>>>>>
>>>>>> Return-Path: <bi...@hotmail.com>
>>>>>> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
>>>>>> Received: from athena.apache.org (HELO athena.apache.org)
>>>>>>             
>>> (140.211.11.136)
>>>       
>>>>>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
>>>>>>             
>>> 00:48:45 +0000
>>>       
>>>>>> X-ASF-Spam-Status: No, hits=2.4 required=5.0
>>>>>>
>>>>>>             
>>>  tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
>>>       
>>>>>> X-Spam-Check-By: apache.org
>>>>>> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.comdesignates 65.55.90.77 as permitted sender)
>>>>>> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com)
>>>>>>             
>>> (65.55.90.77)
>>>       
>>>>>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
>>>>>>             
>>> 00:48:36 +0000
>>>       
>>>>>> Received: from SNT145-W136 ([65.55.90.71]) by
>>>>>>             
>>> snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
>>>       
>>>>>>     Sat, 1 Sep 2012 17:48:15 -0700
>>>>>> Message-ID: <SN...@phx.gbl>
>>>>>> Content-Type: multipart/alternative;
>>>>>>    boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
>>>>>> X-Originating-IP: [122.18.73.194]
>>>>>> From: Bishnu Gautam <bi...@hotmail.com>
>>>>>> To:
>>>>>>    <dev-sc.1346546661.bpbohbfainpplmmplpaj-bishnu35=
>>>>>>             
>>> hotmail.com@river.apache.org>
>>>       
>>>>>> Subject: RE: confirm subscribe to dev@river.apache.org
>>>>>> Date: Sun, 2 Sep 2012 00:48:15 +0000
>>>>>> Importance: Normal
>>>>>> In-Reply-To: <13...@river.apache.org>
>>>>>> References: <13...@river.apache.org>
>>>>>> MIME-Version: 1.0
>>>>>> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC)
>>>>>>             
>>> FILETIME=[A3545700:01CD88A4]
>>>       
>>>>>> X-Virus-Checked: Checked by ClamAV on apache.org
>>>>>>
>>>>>>
>>>>>>             
>>>>>           
>>>       
>  		 	   		  
>   


RE: WELCOME to dev@river.apache.org

Posted by Bishnu Gautam <bi...@hotmail.com>.
Hi
No, I am not using ServiceUI, instead, I have written myself that exports the wrapped services to the client. We can still export the very light weight browser as jini service too. In that way, we can still make our jini services that can run in client machine. I am calling this browser as Universal Browser.  I have written a paper about this scenario more in detail at following paper:
http://www.iaeng.org/publication/IMECS2010/IMECS2010_pp638-643.pdf 
You may find number of services running in the browser including web browser. Yes, this is the right time how we can make good service interface that can be used by client at end.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Tue, 4 Sep 2012 08:12:24 +0100
> Subject: Re: WELCOME to dev@river.apache.org
> From: dan.creswell@gmail.com
> To: dev@river.apache.org
> 
> Can you say a little more about the JPanel wrapping? Are you making use of
> ServiceUI or custom generating something or ?
> 
> The reason I'm asking is because for client-side exposure of graphical
> material, a browser is a good place to go especially with the arrival of
> HTML5. In fact, perhaps it's time we re-evaluated ServiceUI...
> 
> On 4 September 2012 01:26, Bishnu Gautam <bi...@hotmail.com> wrote:
> 
> >
> >
> > Hi Peter and Simon
> > Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is
> > better than TCP. I am very interested to use Java UDT and totally agree to
> > apply this protocol. That will efficiently work I think. I am building an
> > application that transfer all bundled JPanel wraped jini/river services to
> > client sides. I am able to execute it in muliti-Lan environment. I will
> > donate this code to river community. My next phase is to implement it to
> > execute in internet. If you guys have already implemented some of it, lets
> > share the codes or lets discuss so that we can bring river project as one
> > of the demanding solution not only in distributed environment but also for
> > the cloud community. I think this is the right time for jini/river
> > community to come into the business or into the cloud.
> > RegardsBishnu
> >
> >
> >
> >
> > Bishnu Prasad Gautam
> >
> >
> > > Date: Mon, 3 Sep 2012 18:12:55 +1000
> > > From: jini@zeus.net.au
> > > To: dev@river.apache.org
> > > Subject: Re: WELCOME to dev@river.apache.org
> > >
> > > Thanks Bishnu, welcome to River!
> > >
> > > I've had some plans with regard to internet based services, not much
> > > implemented I'm afraid, time constraints...
> > >
> > >    1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
> > >       internet based service registrars (lookup service).
> > >    2. DNS-SRV Discovery, to use in place of multicast discovery, this
> > >       (not yet implemented) discovers the location of lookup services,
> > >       to be used in Unicast Discovery.
> > >    3. Java UDT Sockets - not yet implemented, this is basically Data
> > >       over UDP, which is easier to get through firewalls than TCP.
> > >
> > > Regards,
> > >
> > > Peter.
> > >
> > > Bishnu Gautam wrote:
> > > > Hello River Team
> > > > It seems that Jini is getting its pace in terms of River. This is good
> > indication and I think that River has great potential if we can build some
> > application that can interact over Internet.I am planning to do a research
> > work whether we can make an application of River that can interact over
> > internet as I found there are some issues of firewall etc. Would you let me
> > know, whether the River team has plan of bringing River on the Internet ?
> > > >
> > > > Bishnu Prasad Gautam
> > > >
> > > >
> > > >> Date: Sun, 2 Sep 2012 00:48:45 +0000
> > > >> From: dev-help@river.apache.org
> > > >> To: bishnu35@hotmail.com
> > > >> Subject: WELCOME to dev@river.apache.org
> > > >>
> > > >> Hi! This is the ezmlm program. I'm managing the
> > > >> dev@river.apache.org mailing list.
> > > >>
> > > >> I'm working for my owner, who can be reached
> > > >> at dev-owner@river.apache.org.
> > > >>
> > > >> Acknowledgment: I have added the address
> > > >>
> > > >>    bishnu35@hotmail.com
> > > >>
> > > >> to the dev mailing list.
> > > >>
> > > >> Welcome to dev@river.apache.org!
> > > >>
> > > >> Please save this message so that you know the address you are
> > > >> subscribed under, in case you later want to unsubscribe or change your
> > > >> subscription address.
> > > >>
> > > >>
> > > >> --- Administrative commands for the dev list ---
> > > >>
> > > >> I can handle administrative requests automatically. Please
> > > >> do not send them to the list address! Instead, send
> > > >> your message to the correct command address:
> > > >>
> > > >> To subscribe to the list, send a message to:
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> To remove your address from the list, send a message to:
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> Send mail to the following for info and FAQ for this list:
> > > >>    <de...@river.apache.org>
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> Similar addresses exist for the digest list:
> > > >>    <de...@river.apache.org>
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> To get messages 123 through 145 (a maximum of 100 per request), mail:
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> To get an index with subject and author for messages 123-456 , mail:
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> They are always returned as sets of 100, max 2000 per request,
> > > >> so you'll actually get 100-499.
> > > >>
> > > >> To receive all messages with the same subject as message 12345,
> > > >> send a short message to:
> > > >>    <de...@river.apache.org>
> > > >>
> > > >> The messages should contain one line or word of text to avoid being
> > > >> treated as sp@m, but I will ignore their content.
> > > >> Only the ADDRESS you send to is important.
> > > >>
> > > >> You can start a subscription for an alternate address,
> > > >> for example "john@host.domain", just add a hyphen and your
> > > >> address (with '=' instead of '@') after the command word:
> > > >> <de...@river.apache.org>
> > > >>
> > > >> To stop subscription for this address, mail:
> > > >> <de...@river.apache.org>
> > > >>
> > > >> In both cases, I'll send a confirmation message to that address. When
> > > >> you receive it, simply reply to it to complete your subscription.
> > > >>
> > > >> If despite following these instructions, you do not get the
> > > >> desired results, please contact my owner at
> > > >> dev-owner@river.apache.org. Please be patient, my owner is a
> > > >> lot slower than I am ;-)
> > > >>
> > > >> --- Enclosed is a copy of the request I received.
> > > >>
> > > >> Return-Path: <bi...@hotmail.com>
> > > >> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
> > > >> Received: from athena.apache.org (HELO athena.apache.org)
> > (140.211.11.136)
> > > >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
> > 00:48:45 +0000
> > > >> X-ASF-Spam-Status: No, hits=2.4 required=5.0
> > > >>
> >  tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
> > > >> X-Spam-Check-By: apache.org
> > > >> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.comdesignates 65.55.90.77 as permitted sender)
> > > >> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com)
> > (65.55.90.77)
> > > >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
> > 00:48:36 +0000
> > > >> Received: from SNT145-W136 ([65.55.90.71]) by
> > snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
> > > >>     Sat, 1 Sep 2012 17:48:15 -0700
> > > >> Message-ID: <SN...@phx.gbl>
> > > >> Content-Type: multipart/alternative;
> > > >>    boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
> > > >> X-Originating-IP: [122.18.73.194]
> > > >> From: Bishnu Gautam <bi...@hotmail.com>
> > > >> To:
> > > >>    <dev-sc.1346546661.bpbohbfainpplmmplpaj-bishnu35=
> > hotmail.com@river.apache.org>
> > > >> Subject: RE: confirm subscribe to dev@river.apache.org
> > > >> Date: Sun, 2 Sep 2012 00:48:15 +0000
> > > >> Importance: Normal
> > > >> In-Reply-To: <13...@river.apache.org>
> > > >> References: <13...@river.apache.org>
> > > >> MIME-Version: 1.0
> > > >> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC)
> > FILETIME=[A3545700:01CD88A4]
> > > >> X-Virus-Checked: Checked by ClamAV on apache.org
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
> >
 		 	   		  

Re: WELCOME to dev@river.apache.org

Posted by Dan Creswell <da...@gmail.com>.
Can you say a little more about the JPanel wrapping? Are you making use of
ServiceUI or custom generating something or ?

The reason I'm asking is because for client-side exposure of graphical
material, a browser is a good place to go especially with the arrival of
HTML5. In fact, perhaps it's time we re-evaluated ServiceUI...

On 4 September 2012 01:26, Bishnu Gautam <bi...@hotmail.com> wrote:

>
>
> Hi Peter and Simon
> Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is
> better than TCP. I am very interested to use Java UDT and totally agree to
> apply this protocol. That will efficiently work I think. I am building an
> application that transfer all bundled JPanel wraped jini/river services to
> client sides. I am able to execute it in muliti-Lan environment. I will
> donate this code to river community. My next phase is to implement it to
> execute in internet. If you guys have already implemented some of it, lets
> share the codes or lets discuss so that we can bring river project as one
> of the demanding solution not only in distributed environment but also for
> the cloud community. I think this is the right time for jini/river
> community to come into the business or into the cloud.
> RegardsBishnu
>
>
>
>
> Bishnu Prasad Gautam
>
>
> > Date: Mon, 3 Sep 2012 18:12:55 +1000
> > From: jini@zeus.net.au
> > To: dev@river.apache.org
> > Subject: Re: WELCOME to dev@river.apache.org
> >
> > Thanks Bishnu, welcome to River!
> >
> > I've had some plans with regard to internet based services, not much
> > implemented I'm afraid, time constraints...
> >
> >    1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
> >       internet based service registrars (lookup service).
> >    2. DNS-SRV Discovery, to use in place of multicast discovery, this
> >       (not yet implemented) discovers the location of lookup services,
> >       to be used in Unicast Discovery.
> >    3. Java UDT Sockets - not yet implemented, this is basically Data
> >       over UDP, which is easier to get through firewalls than TCP.
> >
> > Regards,
> >
> > Peter.
> >
> > Bishnu Gautam wrote:
> > > Hello River Team
> > > It seems that Jini is getting its pace in terms of River. This is good
> indication and I think that River has great potential if we can build some
> application that can interact over Internet.I am planning to do a research
> work whether we can make an application of River that can interact over
> internet as I found there are some issues of firewall etc. Would you let me
> know, whether the River team has plan of bringing River on the Internet ?
> > >
> > > Bishnu Prasad Gautam
> > >
> > >
> > >> Date: Sun, 2 Sep 2012 00:48:45 +0000
> > >> From: dev-help@river.apache.org
> > >> To: bishnu35@hotmail.com
> > >> Subject: WELCOME to dev@river.apache.org
> > >>
> > >> Hi! This is the ezmlm program. I'm managing the
> > >> dev@river.apache.org mailing list.
> > >>
> > >> I'm working for my owner, who can be reached
> > >> at dev-owner@river.apache.org.
> > >>
> > >> Acknowledgment: I have added the address
> > >>
> > >>    bishnu35@hotmail.com
> > >>
> > >> to the dev mailing list.
> > >>
> > >> Welcome to dev@river.apache.org!
> > >>
> > >> Please save this message so that you know the address you are
> > >> subscribed under, in case you later want to unsubscribe or change your
> > >> subscription address.
> > >>
> > >>
> > >> --- Administrative commands for the dev list ---
> > >>
> > >> I can handle administrative requests automatically. Please
> > >> do not send them to the list address! Instead, send
> > >> your message to the correct command address:
> > >>
> > >> To subscribe to the list, send a message to:
> > >>    <de...@river.apache.org>
> > >>
> > >> To remove your address from the list, send a message to:
> > >>    <de...@river.apache.org>
> > >>
> > >> Send mail to the following for info and FAQ for this list:
> > >>    <de...@river.apache.org>
> > >>    <de...@river.apache.org>
> > >>
> > >> Similar addresses exist for the digest list:
> > >>    <de...@river.apache.org>
> > >>    <de...@river.apache.org>
> > >>
> > >> To get messages 123 through 145 (a maximum of 100 per request), mail:
> > >>    <de...@river.apache.org>
> > >>
> > >> To get an index with subject and author for messages 123-456 , mail:
> > >>    <de...@river.apache.org>
> > >>
> > >> They are always returned as sets of 100, max 2000 per request,
> > >> so you'll actually get 100-499.
> > >>
> > >> To receive all messages with the same subject as message 12345,
> > >> send a short message to:
> > >>    <de...@river.apache.org>
> > >>
> > >> The messages should contain one line or word of text to avoid being
> > >> treated as sp@m, but I will ignore their content.
> > >> Only the ADDRESS you send to is important.
> > >>
> > >> You can start a subscription for an alternate address,
> > >> for example "john@host.domain", just add a hyphen and your
> > >> address (with '=' instead of '@') after the command word:
> > >> <de...@river.apache.org>
> > >>
> > >> To stop subscription for this address, mail:
> > >> <de...@river.apache.org>
> > >>
> > >> In both cases, I'll send a confirmation message to that address. When
> > >> you receive it, simply reply to it to complete your subscription.
> > >>
> > >> If despite following these instructions, you do not get the
> > >> desired results, please contact my owner at
> > >> dev-owner@river.apache.org. Please be patient, my owner is a
> > >> lot slower than I am ;-)
> > >>
> > >> --- Enclosed is a copy of the request I received.
> > >>
> > >> Return-Path: <bi...@hotmail.com>
> > >> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
> > >> Received: from athena.apache.org (HELO athena.apache.org)
> (140.211.11.136)
> > >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
> 00:48:45 +0000
> > >> X-ASF-Spam-Status: No, hits=2.4 required=5.0
> > >>
>  tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
> > >> X-Spam-Check-By: apache.org
> > >> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.comdesignates 65.55.90.77 as permitted sender)
> > >> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com)
> (65.55.90.77)
> > >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
> 00:48:36 +0000
> > >> Received: from SNT145-W136 ([65.55.90.71]) by
> snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
> > >>     Sat, 1 Sep 2012 17:48:15 -0700
> > >> Message-ID: <SN...@phx.gbl>
> > >> Content-Type: multipart/alternative;
> > >>    boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
> > >> X-Originating-IP: [122.18.73.194]
> > >> From: Bishnu Gautam <bi...@hotmail.com>
> > >> To:
> > >>    <dev-sc.1346546661.bpbohbfainpplmmplpaj-bishnu35=
> hotmail.com@river.apache.org>
> > >> Subject: RE: confirm subscribe to dev@river.apache.org
> > >> Date: Sun, 2 Sep 2012 00:48:15 +0000
> > >> Importance: Normal
> > >> In-Reply-To: <13...@river.apache.org>
> > >> References: <13...@river.apache.org>
> > >> MIME-Version: 1.0
> > >> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC)
> FILETIME=[A3545700:01CD88A4]
> > >> X-Virus-Checked: Checked by ClamAV on apache.org
> > >>
> > >>
> > >
> > >
> >
>
>

RE: WELCOME to dev@river.apache.org

Posted by Bishnu Gautam <bi...@hotmail.com>.

Hi Peter and Simon
Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is better than TCP. I am very interested to use Java UDT and totally agree to apply this protocol. That will efficiently work I think. I am building an application that transfer all bundled JPanel wraped jini/river services to client sides. I am able to execute it in muliti-Lan environment. I will donate this code to river community. My next phase is to implement it to execute in internet. If you guys have already implemented some of it, lets share the codes or lets discuss so that we can bring river project as one of the demanding solution not only in distributed environment but also for the cloud community. I think this is the right time for jini/river community to come into the business or into the cloud.
RegardsBishnu




Bishnu Prasad Gautam


> Date: Mon, 3 Sep 2012 18:12:55 +1000
> From: jini@zeus.net.au
> To: dev@river.apache.org
> Subject: Re: WELCOME to dev@river.apache.org
> 
> Thanks Bishnu, welcome to River!
> 
> I've had some plans with regard to internet based services, not much 
> implemented I'm afraid, time constraints...
> 
>    1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
>       internet based service registrars (lookup service).
>    2. DNS-SRV Discovery, to use in place of multicast discovery, this
>       (not yet implemented) discovers the location of lookup services,
>       to be used in Unicast Discovery.
>    3. Java UDT Sockets - not yet implemented, this is basically Data
>       over UDP, which is easier to get through firewalls than TCP.
> 
> Regards,
> 
> Peter.
> 
> Bishnu Gautam wrote:
> > Hello River Team
> > It seems that Jini is getting its pace in terms of River. This is good indication and I think that River has great potential if we can build some application that can interact over Internet.I am planning to do a research work whether we can make an application of River that can interact over internet as I found there are some issues of firewall etc. Would you let me know, whether the River team has plan of bringing River on the Internet ? 
> >
> > Bishnu Prasad Gautam 
> >
> >   
> >> Date: Sun, 2 Sep 2012 00:48:45 +0000
> >> From: dev-help@river.apache.org
> >> To: bishnu35@hotmail.com
> >> Subject: WELCOME to dev@river.apache.org
> >>
> >> Hi! This is the ezmlm program. I'm managing the
> >> dev@river.apache.org mailing list.
> >>
> >> I'm working for my owner, who can be reached
> >> at dev-owner@river.apache.org.
> >>
> >> Acknowledgment: I have added the address
> >>
> >>    bishnu35@hotmail.com
> >>
> >> to the dev mailing list.
> >>
> >> Welcome to dev@river.apache.org!
> >>
> >> Please save this message so that you know the address you are
> >> subscribed under, in case you later want to unsubscribe or change your
> >> subscription address.
> >>
> >>
> >> --- Administrative commands for the dev list ---
> >>
> >> I can handle administrative requests automatically. Please
> >> do not send them to the list address! Instead, send
> >> your message to the correct command address:
> >>
> >> To subscribe to the list, send a message to:
> >>    <de...@river.apache.org>
> >>
> >> To remove your address from the list, send a message to:
> >>    <de...@river.apache.org>
> >>
> >> Send mail to the following for info and FAQ for this list:
> >>    <de...@river.apache.org>
> >>    <de...@river.apache.org>
> >>
> >> Similar addresses exist for the digest list:
> >>    <de...@river.apache.org>
> >>    <de...@river.apache.org>
> >>
> >> To get messages 123 through 145 (a maximum of 100 per request), mail:
> >>    <de...@river.apache.org>
> >>
> >> To get an index with subject and author for messages 123-456 , mail:
> >>    <de...@river.apache.org>
> >>
> >> They are always returned as sets of 100, max 2000 per request,
> >> so you'll actually get 100-499.
> >>
> >> To receive all messages with the same subject as message 12345,
> >> send a short message to:
> >>    <de...@river.apache.org>
> >>
> >> The messages should contain one line or word of text to avoid being
> >> treated as sp@m, but I will ignore their content.
> >> Only the ADDRESS you send to is important.
> >>
> >> You can start a subscription for an alternate address,
> >> for example "john@host.domain", just add a hyphen and your
> >> address (with '=' instead of '@') after the command word:
> >> <de...@river.apache.org>
> >>
> >> To stop subscription for this address, mail:
> >> <de...@river.apache.org>
> >>
> >> In both cases, I'll send a confirmation message to that address. When
> >> you receive it, simply reply to it to complete your subscription.
> >>
> >> If despite following these instructions, you do not get the
> >> desired results, please contact my owner at
> >> dev-owner@river.apache.org. Please be patient, my owner is a
> >> lot slower than I am ;-)
> >>
> >> --- Enclosed is a copy of the request I received.
> >>
> >> Return-Path: <bi...@hotmail.com>
> >> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
> >> Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
> >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:45 +0000
> >> X-ASF-Spam-Status: No, hits=2.4 required=5.0
> >> 	tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
> >> X-Spam-Check-By: apache.org
> >> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.com designates 65.55.90.77 as permitted sender)
> >> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com) (65.55.90.77)
> >>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:36 +0000
> >> Received: from SNT145-W136 ([65.55.90.71]) by snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
> >> 	 Sat, 1 Sep 2012 17:48:15 -0700
> >> Message-ID: <SN...@phx.gbl>
> >> Content-Type: multipart/alternative;
> >> 	boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
> >> X-Originating-IP: [122.18.73.194]
> >> From: Bishnu Gautam <bi...@hotmail.com>
> >> To:
> >> 	<de...@river.apache.org>
> >> Subject: RE: confirm subscribe to dev@river.apache.org
> >> Date: Sun, 2 Sep 2012 00:48:15 +0000
> >> Importance: Normal
> >> In-Reply-To: <13...@river.apache.org>
> >> References: <13...@river.apache.org>
> >> MIME-Version: 1.0
> >> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC) FILETIME=[A3545700:01CD88A4]
> >> X-Virus-Checked: Checked by ClamAV on apache.org
> >>
> >>     
> >  		 	   		  
> >   
> 
 		 	   		  

Re: WELCOME to dev@river.apache.org

Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Bishnu, welcome to River!

I've had some plans with regard to internet based services, not much 
implemented I'm afraid, time constraints...

   1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
      internet based service registrars (lookup service).
   2. DNS-SRV Discovery, to use in place of multicast discovery, this
      (not yet implemented) discovers the location of lookup services,
      to be used in Unicast Discovery.
   3. Java UDT Sockets - not yet implemented, this is basically Data
      over UDP, which is easier to get through firewalls than TCP.

Regards,

Peter.

Bishnu Gautam wrote:
> Hello River Team
> It seems that Jini is getting its pace in terms of River. This is good indication and I think that River has great potential if we can build some application that can interact over Internet.I am planning to do a research work whether we can make an application of River that can interact over internet as I found there are some issues of firewall etc. Would you let me know, whether the River team has plan of bringing River on the Internet ? 
>
> Bishnu Prasad Gautam 
>
>   
>> Date: Sun, 2 Sep 2012 00:48:45 +0000
>> From: dev-help@river.apache.org
>> To: bishnu35@hotmail.com
>> Subject: WELCOME to dev@river.apache.org
>>
>> Hi! This is the ezmlm program. I'm managing the
>> dev@river.apache.org mailing list.
>>
>> I'm working for my owner, who can be reached
>> at dev-owner@river.apache.org.
>>
>> Acknowledgment: I have added the address
>>
>>    bishnu35@hotmail.com
>>
>> to the dev mailing list.
>>
>> Welcome to dev@river.apache.org!
>>
>> Please save this message so that you know the address you are
>> subscribed under, in case you later want to unsubscribe or change your
>> subscription address.
>>
>>
>> --- Administrative commands for the dev list ---
>>
>> I can handle administrative requests automatically. Please
>> do not send them to the list address! Instead, send
>> your message to the correct command address:
>>
>> To subscribe to the list, send a message to:
>>    <de...@river.apache.org>
>>
>> To remove your address from the list, send a message to:
>>    <de...@river.apache.org>
>>
>> Send mail to the following for info and FAQ for this list:
>>    <de...@river.apache.org>
>>    <de...@river.apache.org>
>>
>> Similar addresses exist for the digest list:
>>    <de...@river.apache.org>
>>    <de...@river.apache.org>
>>
>> To get messages 123 through 145 (a maximum of 100 per request), mail:
>>    <de...@river.apache.org>
>>
>> To get an index with subject and author for messages 123-456 , mail:
>>    <de...@river.apache.org>
>>
>> They are always returned as sets of 100, max 2000 per request,
>> so you'll actually get 100-499.
>>
>> To receive all messages with the same subject as message 12345,
>> send a short message to:
>>    <de...@river.apache.org>
>>
>> The messages should contain one line or word of text to avoid being
>> treated as sp@m, but I will ignore their content.
>> Only the ADDRESS you send to is important.
>>
>> You can start a subscription for an alternate address,
>> for example "john@host.domain", just add a hyphen and your
>> address (with '=' instead of '@') after the command word:
>> <de...@river.apache.org>
>>
>> To stop subscription for this address, mail:
>> <de...@river.apache.org>
>>
>> In both cases, I'll send a confirmation message to that address. When
>> you receive it, simply reply to it to complete your subscription.
>>
>> If despite following these instructions, you do not get the
>> desired results, please contact my owner at
>> dev-owner@river.apache.org. Please be patient, my owner is a
>> lot slower than I am ;-)
>>
>> --- Enclosed is a copy of the request I received.
>>
>> Return-Path: <bi...@hotmail.com>
>> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
>> Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:45 +0000
>> X-ASF-Spam-Status: No, hits=2.4 required=5.0
>> 	tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
>> X-Spam-Check-By: apache.org
>> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.com designates 65.55.90.77 as permitted sender)
>> Received: from [65.55.90.77] (HELO snt0-omc2-s2.snt0.hotmail.com) (65.55.90.77)
>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012 00:48:36 +0000
>> Received: from SNT145-W136 ([65.55.90.71]) by snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
>> 	 Sat, 1 Sep 2012 17:48:15 -0700
>> Message-ID: <SN...@phx.gbl>
>> Content-Type: multipart/alternative;
>> 	boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
>> X-Originating-IP: [122.18.73.194]
>> From: Bishnu Gautam <bi...@hotmail.com>
>> To:
>> 	<de...@river.apache.org>
>> Subject: RE: confirm subscribe to dev@river.apache.org
>> Date: Sun, 2 Sep 2012 00:48:15 +0000
>> Importance: Normal
>> In-Reply-To: <13...@river.apache.org>
>> References: <13...@river.apache.org>
>> MIME-Version: 1.0
>> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC) FILETIME=[A3545700:01CD88A4]
>> X-Virus-Checked: Checked by ClamAV on apache.org
>>
>>     
>  		 	   		  
>