home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / isis / 347 < prev    next >
Encoding:
Text File  |  1992-12-25  |  1.4 KB  |  31 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!mcsun!inesc.inesc.pt!freya.inesc.pt!werner
  3. From: werner@freya.inesc.pt (Werner Vogels)
  4. Subject: Re: FDDI multicast?
  5. Message-ID: <1992Dec25.160102.7281@inesc.pt>
  6. Sender: usenet@inesc.pt (USENET News System)
  7. Nntp-Posting-Host: freya.inesc.pt
  8. Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal
  9. References:  <1992Dec25.032548.13096@cs.cornell.edu>
  10. Date: Fri, 25 Dec 1992 16:01:02 GMT
  11. Lines: 18
  12.  
  13. In article <1992Dec25.032548.13096@cs.cornell.edu>, ken@cs.cornell.edu (Ken Birman) writes:
  14. |> Werner's message leaves me curious: how does one get at FDDI
  15. |> multicast from UNIX?  Is the "model" similar to ipmcast?
  16.  
  17. The model is independent of ipmcast, You just need an ioctl to your 
  18. controller to add and delete mcast addresses. Like it happends now 
  19. in if_ether.c you will need a CLASSD to MAC address conversion and problably 
  20. you want some bookkeeping. The real hardware stuff is left to the device 
  21. driver. If the driver is correctly written you do not really need to keep
  22. much state about duplicate joins of ipmcast groups; the driver should
  23. maintain this itself. In the pre ipmcast SunOS 4.1.1 days you could 
  24. find the multicast addresses at controller in the arpcom structure which 
  25. is part of every if es_if (ethernet), but the new ipmcast ethernet module 
  26. does different bookkeeping.
  27.  
  28. --
  29. Werner
  30.  
  31.