Re: Applet receiving multicast msg ?

Pascal Ledru (pledru@pluto.cs.uah.edu)
Sun, 10 May 1998 23:25:34 -0500 (CDT)

From: Pascal Ledru <pledru@pluto.cs.uah.edu>
Message-Id: <199805110425.XAA13301@pluto.cs.uah.edu>
Subject: Re: Applet receiving multicast msg ?
To: Roland.Schemers@Eng (Roland Schemers)
Date: Sun, 10 May 1998 23:25:34 -0500 (CDT)
In-Reply-To: <199804300641.XAA02227@crypto.eng.sun.com> from "Roland Schemers" at Apr 29, 98 11:41:11 pm

Sent you this one last week but it came back:
Roland,
Thanks for your answer.

What I was considering is a little bit different from
what you describe.
I want an UNTRUSTED applet to be able to receive a multicast message
from the host the applet is from . (Since I am going to have a group of
Applets and would like to send only one message. Also since I am working
with Applets, I cannot overwrite the security manager)

My point is that checkMulticast is not necessary in joinGroup
but of course need to stay in send (where it will never be able to send
a multicast message) and receive (where it will only be able to receive
a message from the host the applet is from)
In receive, it is possible to detect where the multicast message is coming
from with a call such as dp.getAddress().getHostName()

Note that with multicasting, it is necessary for the RECEIVER to join a group
since under the hood, there is probably a call such as:
setsockopt(sock, IPPROTO_IP. IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)
but the SENDER actually can use a regular datagram with a multicast address.

On the other hand, with BROADCASTING (255.255.255.255), the RECEIVER does not ne
ed
to be modified, but the SENDER need to add something like:
setsockopt(sock, SOL_SOCKET, SO_BROADCAST)

So, I didn't try it yet but I think
An applet CAN receive a broadcast message (from a program written in C since Jav
a
does not allow to set up broadcasting I think) using plain datagrams if the msg
come from the host where the applet is from, but it CANNOT receive a multicast
message from the host the applet is from.

This is certainly NOT consistent.

Does it make sense, and is it something you may considerer in a future
release (when?) or is there something obvious I am missing.

Thank you

Pascal Ledru

> I have often wondered the same thing myself. Since multi-cast addresses
> are just class D IP addresses I'm not sure why checkConnect/etc didn't
> cut it. In 1.2 the default implementations of checkMulticast
> in SecurityManager simply convert the IP address to a string and
> call checkConnect. People are still free to implement their own
> version of checkMulticast though.
>
> Maybe in JDK 1.1.7 we should allow trusted-signed applets to do
> multicasting. That seems like a reasonable fix. We are already
> planning on allowing trusted applets to access the event queue
> and delete files (that they are allowed to write to).
>
> roland
>
> >
> > It seems that Applets cannot receive and send multicast messages.
> >
> > In the MulticastSocket class checkMulticast is called in joinGroup and in send.
> >
> > So an applet will not be able to receive a multicast msg even if the multicast
> > msg is from the host where the applet is from.
> >
> > It seems to me that this is too restrictive.
> > Why is it necessary to call checkMulticast in joinGroup and not only in send
> > and receive? (where in receive it will check that the msg is coming from the
> > host where the Applet is from with a call such as dp.getAddress().getHostName()
> > )
> >
> > It seems to me that this preclude lot of applications where I don't see
> > security problems.
> >
> > For example, if RMI one day support MulticastRemoteObject, the Applet stock
> > notification example given by Sun could be implemented with
> > MulticastRemoteobject
> > which itself would probably use a MulticastSocket (only for receiving msg)
> >
> > Does anybody known why Applets cannot receive multicast msg?
> >
> > Thanks?
> >
> > Pascal Ledru
> >
>
>