The source address of a given multicast packet is the source address of the interface which sent it; just like in unicast. So you've got the same ability to grab the source address, probably via raw sockets. To give an example of one API which exposes this in v4(and the API is reported to be backward compatible for v6 in 1.4) see the following URL. The data is available, APIs for accessing this might be less documented, but you're application can solve this in otherways. http://java.sun.com/products/jdk/1.2/docs/api/java/net/DatagramSocketImpl.ht ml#peek(java.net.InetAddress)
The Anycast situation I described carries the same issues at an application layer that multicast or broadcasts do. From your description it sounds to me like you're leaning on these things to bootstrap your application and provided the needed information to setup the unicast sessions that will be used beyond the bootstrapping phase. The Internet with NATs and other translational/proxying devices is a challenging world to build applications in and there are so many areas to pay attention to that it goes beyond simple v6 public service and starts to become Profe$$onal Advice, which I'm sure you can find plenty of folks to help you with. -Darrell Marcelo Taube wrote: > My only problem with Multicast is that the socket getting a package cannot > know the ip address of the socket who sent it, right??? > At least that's what i have read. > If i cannot know that IP address i cannot establish the unicast connections > later, can i? > (anywhere tell me where can i find something in the net to read about > multicast on both linux and windows) > > > The anycast solution could work but i don't like the idea of registering the > users because users can turn computers off without closing the programm > correctly and that would mean not unregistering. Also when the anycast > server is turned off the clients running are not registered anywhere. > > > ----Original Message Follows---- > From: "Darrell Newcomb" <[EMAIL PROTECTED]> > To: "Marcelo Taube" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > Subject: Re: Broadcasting > Date: Tue, 7 Jan 2003 14:59:46 -0800 > > There is nothing in your description which makes broadcasts more attractive > than multicast. Obviously there are some factors, but they probably aren't > much of a hurdle. A specifically when compairing against broadcasts as the > other option, multicast becomes much more attractive. > > Your application could just as easily join a multicast group and send a > multicast announcement to that group. By going multicast you have a higher > probability of getting a broader distribution of the announcement. And you > don't have to push requirements on the networks your application operates > in...such as allowing directed broadcasts inside some (sub)set of their > network. > > If you're worried about the deployment penetration of multicast, then maybe > you should explore using an anycast registration model. Not that this > doesn't carry it's own issues, but it has the ability to be more robust for > large footprints. > 1)Application starts and sends request to anycast address. > 2)If after some reasonable time no answer to request(s), then bring up the > anycast address on a local interface and announce it to the network. Bind > whatever service that passes out the directory of registered clients. > 3)If you get a response out of step1, then use the data to build your > uni-cast mesh. > 4)You can even have redundancy by doing step2 here and implementing some > sync'ing between the anycast servers. > > Maybe I misunderstood and link local is what you're after with the > broadcasts.. then just use link local. > > Darrell Newcomb > darrell(at)hayaitacos<dot>net > http://www.hayaitacos.net/mpeer *Managed Peering* > > ----- Original Message ----- > From: "Marcelo Taube" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, January 07, 2003 2:03 PM > Subject: Broadcasting > > > > Is broadcasting available over IPv6??? > > I know everyone will tell me to use multicast instead of broadcast. > > But multicast is not usefull to me because it doesn't let me know where > the > > package came from, with broadcasting i can know who sent the message. > > This is important because i need to know who is using the programm on > > different computers. When i open my programm i send a message asking who > is > > here... and other copies of my programm running on other computers > answer. > > Then i establish unicast connections between them. > > So how can i do broadcast in ipv6??? > > and if i can't, how should i do to know where my programm is running? > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > --------------------------------------------------------------------- > > The IPv6 Users Mailing List > > Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED] > > > _________________________________________________________________ > Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
