Page 1 of 1
Multicast support
Posted: Fri Feb 15, 2008 1:50 am
by jeffreyscurtis
I would like to see native support for joining multicast groups.
Jeff
Re: Multicast support
Posted: Mon Apr 21, 2014 11:49 pm
by DarScott
Yeah. This would be nice. Any workarounds?
Re: Multicast support
Posted: Sun Apr 27, 2014 12:17 am
by DarScott
Maybe multicast can be supported with some sort of socket options enhancement. Or an enhancement of the 'accept' command. The first might be more general.
Re: Multicast support
Posted: Sat May 03, 2014 9:43 pm
by DarScott
Or maybe (as inspired by imagePixmapID), there could be a function to get the handle of the socket and this can be passed to an external.
Re: Multicast support
Posted: Wed May 14, 2014 6:23 am
by DarScott
Here is how it might be done without socket options:
An 'open datagram socket' is allowed to have an IP address in the multicast range. If a nonempty value is specified in defaultNetworkInterface then, it is set appropriately for the outgoing source socket. Loopback is enabled to allow receivers to be on the same computer. The TTL is left at 1; allowing use only in the local LAN. No syntax change is needed.
The 'accept datagram socket' command is enhanced to allow the optional clause 'from group <IP-address>'. This allows datagrams to be received from the specified multicast group. No other groups can be added for that port. No source list or source blocking is available.
Buffer sizes are set to at least the maximum size of a datagram socket in both cases.
Re: Multicast support
Posted: Fri Aug 15, 2014 11:46 pm
by DarScott
An alternative to the optional clause 'from group <ip address>' for accept is to allow an address:port pair where a port is used.
This it might be like this:
Code: Select all
accept datagram connections on port 239.9.4.211:5000 with message "gotDatagram"
One problem with that is that (as is) it looks the same in openSockets as a socket opened for sending datagrams to the multicast group.
The solution for that would be the same as that for the problem of accept datagram and accept for TCP looking the same in openSockets. Allowing an ID (connection name) suffix after a vertical bar (as is allowed with open socket) can make sure the accept and the open socket designators are distinct.
This might be simpler and easier to understand. It does not grow that well when multiple groups are added.
So, there are these two syntaxes to consider for enhancing accept datagram and the possibility of I/O properties in general or socket options in specific.