https://bugzilla.novell.com/show_bug.cgi?id=655153
https://bugzilla.novell.com/show_bug.cgi?id=655153#c4 --- Comment #4 from Andy Hume <[email protected]> 2010-12-09 20:39:44 UTC --- That would seem to be a shame. Other platforms/frameworks are quite closed such that the methods on their socket take an IP Address and a port number, so hey are fixed to TCP/IP alone. As we know that is _not_ how it is on the .NET framework. Here, as standardised in ECMA TR-084, System.Net.Sockets.Socket is defined having extensible address family support. Socket can accept any subclass of EndPoint to Connect/Bind -- and will also return the correct subclass from Accept/LocalEndPoint/RemoteEndPoint[1]. So it's clear the MSFT and the standardisation committees *have* planned for Socket to be extensible to any address and protocol families. All this support is present in all the FCLs: on all the Microsoft produced frameworks, full/NETCF/etc; and on Mono since many versions. So that is all in place and is all fully compatible. And on Mono this support is used for multiple families: IPv4, IPv6, and Unix Sockets. So already Mono's Sockets has added support for things that one could call incompatible with the MSFT .NET API. There is obviously no support for Unix Sockets there, but Mono has that... The one difference between MSFT platforms and Mono, is that Mono stops one from using this flexibility. Its blocks one from use an address family it hasn't been predefined to know, it doesn't allow one to use to use a sockaddr it hasn't been predefined to know. If it simply allowed one to do so, then there'd be no need for any special code for Bluetooth or any other family, it would just work. All the flexibility in the standard would be available. Maybe that would be more palatable? Rather than having code that handles Bluetooth sockaddrs explicitly, I'd be happy if the runtime just used the sockaddrs supplied by the managed code. The existing support for IPv4, IPv6 and Unix can be left in place but the runtime should passthrough any values it is unaware of. Anyway I hope we can make a change to allow such access. It would seem a real pain to have to create my own P/Invoke code to call socket, bind, accept, getpeername, and getsockname, phew; and then do Reflection poking... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
