9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Multicast example
@ 2010-06-23  5:05 Justin Wilson
  2010-06-23 12:55 ` erik quanstrom
  0 siblings, 1 reply; 2+ messages in thread
From: Justin Wilson @ 2010-06-23  5:05 UTC (permalink / raw)
  To: 9fans

How does one send/receive multicast packets?

I'm assuming that in order to send, one uses something like:
dial("udp!224.100.100.100!64470", nil, nil, nil)

However, I'm not quite sure about receiving.
I see an "addmulti" in ip(3) but I don't quite understand the comment
and I couldn't penetrate the source.

Thanks.

Justin



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [9fans] Multicast example
  2010-06-23  5:05 [9fans] Multicast example Justin Wilson
@ 2010-06-23 12:55 ` erik quanstrom
  0 siblings, 0 replies; 2+ messages in thread
From: erik quanstrom @ 2010-06-23 12:55 UTC (permalink / raw)
  To: 9fans

> However, I'm not quite sure about receiving.
> I see an "addmulti" in ip(3) but I don't quite understand the comment
> and I couldn't penetrate the source.

what comment?  unfortunately, where ip(3) says
"media address", i think it really means ip address.
the code says it accepts
	addmulti $rxaddr $multiaddr
or
	addmulti $multiaddr	# assume $rxaddr = normal rec. addr

ip(3) is quite unclear (to me, anyway) about the
differences between the ip stack's notions and
the interface' notions.  perhaps i notice because
we send a lot of non-ip traffic.

in the case of multicast mac addresses, ip tries to
bridge the gap.  but i don't think that current hardware
works this way.  modern hardware tends to hash
multicast *ethernet* addresses, but not ip addresses.
and that's the way that addmulti/remmulti are implemented
in netif.c and /sys/src/9/pc/ether[a-z]*.c:/^[a-z0-9]+multicast

mind the gap!

also for mtu, ip assumes that it is fixed per medium,
and not per hardware device. this bit from ip(3) is misleading.

- The
- .I mtu
- is the size in bytes of the largest packet that this interface can send.

the mtu for ip(3) is the largest packet that ip tries to send.
this may be larger (that is, misconfigured), smaller or the same
as the interface mtu.  in 9atom, the interface mtu may be
set by
	echo mtu 9000 > /net/ether0/clone
and the /net/ether0/mtu file has the mintu mtu and maxtu.

i have been meaning to let ip discover the current mtu
by reading it from the device, but i need a solution that will
keep the mtu high for aoe even if ip wants it at 1514 to allow
ip to make sure that its idea of the interface (media) mtu
isn't wrong.  i'm also somewhat uncomfortable with managing
the interface via an ip proxy.

we routinely mix 8228-byte aoe packets with 1514-byte ip
packets.  the interface's mtu is set to 9000, while the ip stack's
mtu is set to 1514.

to sum up, i think there is a little confusion in the code.
i'd be interested in your results.

- erik



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-06-23 12:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-23  5:05 [9fans] Multicast example Justin Wilson
2010-06-23 12:55 ` erik quanstrom

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).