[Mono-bugs] [Bug 655153] Add support for Bluetooth sockets

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=655153

https://bugzilla.novell.com/show_bug.cgi?id=655153#c4


--- Comment #4 from Andy Hume <andyhume32 at yahoo.co.uk> 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.