Slashdot Mirror
IBM Does Bluetooth On Linux
Frank Carlos writes: "IBM released Linux-based applications technology based on the Bluetooth specification called BlueDrekar, which is a reference implementation of and a set of interfaces for the Bluetooth protocol stack. You can get the Transport Drivers for BlueDrekar(TM) Middleware at the developerWorks Open Source Zone."
Actually, it's more like how a 3c905 doesn't define any network protocols, because it's just a NIC. You can run netbeui, ipx, tcp/ip, appletalk, or what have you. There's no reason whatsoever that bluetooth shouldn't be the same.
Mind you, bluetooth will probably end up with several different network protocols. (Sorry, I never memorized the burrito's ingredients, so I'm going to speak in layman's terms.) Obviously lots of people will be interested in doing TCP/IP, over which they will almost certainly use DHCP for autoconfiguration. Since they're using TCP/IP they'll get into DNS pretty much by default. So these are all things we can be fairly sure will be present on a significant number of bluetooth devices.
The up side of this is that most of this is present on PDAs already, like the palmpilot, WinCE devices, and so on. They should all be able to interoperate fairly conveniently. Pick your device, do a DHCP request to autoconfigure, starting with LINK-LOCAL addresses, and whoever hears a request first (which probably means that they're the first to send but the other device wasn't ready) sets an IP (in the reserved range) and then serves the other machine's DHCP request.
You could well use simpler protocols like Microsoft's NetBEUI. In fact, on a non-internet-connected LAN made up of only Windows machines, NetBEUI is my default protocol of choice, because it's small and fast, has basically no overhead, and works without any configuration at all (At least, that the user has to see) so perhaps that's the best idea for use on Bluetooth, but since it's only implemented on Windows AFAIK, it's not bloody likely to become a standard. IPX would be another choice, but it's fallen out of favor in recent years, and it's not available on the majority of palmtops in any case.
Regardless of what protocol you choose, it should be TCP/IP :) TCP/IP is the only one that's available in basically every location. Hell, you can make an IBM PC-XT speak TCP/IP with either old dos software, or geoworks. If an XT can do it, I'm sold :)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Bluetooth is being touted as two things. The first is as a replacement for wires. This is certainly happening now. But just because you can string a wire between two devices doesn't mean they'll talk to each other.
The second thing Bluetooth is being touted as is a way to do dynamic networking, and it will make everything talk to everything. However, even TCP/IP isn't included in the spec, so some devices my choose to not support it. In the area of service discovery, there are there different standards that are being pushed... Sun's, Microsoft's, and an open group pushing Salutation. I like Jini the best because its drivers can be used on any platform and the devices can carry their drivers with them. But it doesn't specify a common transport.
Bluetooth seems to only make the Physical, DataLink, and Network layers standard. With more than half of the 7 layer burrito in limbo, I don't know how the protocol stack can hold up.
--
Bluetooth is IrLA on steriods - it isn't line of site, being RF, it can go 10 to 100 meters, and it supports 7 nodes per master radio. They call that a piconet, beyound that you can connect a number of piconets. Not too bad for wiring a wireless home, one piconet per room.
There is a set of "profiles" that are specs on how to communicate between boxes. The profiles I know of are
Generic Access Profile
Service Discovery Profile Application Profile
Cordless Telephony Profile
Intercom Profile
Serial Port profile
Headset Profile
Dial-up Networking Profile
Fax Profile
Lan Access Profile
Generic Object Exchange Profile
Object Push Profile
File Transfer Profile
Synchronization Profile
Looks like a good start to me ... the protocol is royality free, the specs (~1500 pages) on CD do cost $100 - something of a bummer, but you can get them on-line at www.bluetooth.com
http://oss.software.ibm.com/developerworks/opensou rce/tp4bluedrekar/?open&l=sdot,t=gr,p=bd rk
Anyone else notice the l=sdot in there? Since it was submitted by someone at IBM, it would seem that they want to track specifically how many people visit the site after reading it on Slashdot. Conspiracy? Its probably a good thing, since its bound to get tons of visitors and maybe make IBM consider releasing even more software for Linux.
>Until there is a common format, Bluetooth will >fail. I hope someone will take the initaive to >create an open standard for content transfer.
You may be interested to know that IEEE is standardising Bluetooth wireless technology as 802.15 - perhaps they may address some of the issues you mention.
>Bluetooth as a wireless standard will fail. This >is the conclusion that I have come to after >watching the industry very carefully. The >reason? Not enough standardization.
I agree with the lack of standardisation, but I am not sure that it will cause the standard to fail. There is significant momentum behind the technology, and I suspect that will continue to drive it through - but unfortunately, the result may not be as ideal as was hoped.
Personally, there are aspects of the architecture that I think they could have done in a better way. I don't think that the architecture is conceptually abstract and rigid as it could be, and the lack of vision to include bandwidth extensibility, etc.
>So far, there has been no standardization for >content protocols over Bluetooth. The >only "standard" that could be considered close >is wrapping TCP/IP, from which you can get HTTP, >XML, etc. for passing data. However, Bluetooth >as it stands is not going to be the be-all and >end-all of information transfer, because there >is no common format.
I am not sure that there needs to be standardisation for content protocols. Bluetooth includes a Service Discovery Protocol that allows for any myriad of services to be developed and employed.
IMHO that is exactly what Bluetooth should do, just like TCP does not define any content protocols, because it is a transport layer.
>What's needed is a common implementation of a >method for applications to speak to each other >over an open protocol. No manufacturers have >been forthcoming about this. Instead, we see >fracturing of devices, unable to actually speak >to each other.
There is a common method in the Bluetooth SDP; and as far as I can see it does not preclude the use of something like Jini.
One problem I do see is that Bluetooth was designed to be something like an IrDA replacement, but now it is taken and used for other things outside of its design envelope. The question is whether the original conception of the design had enough vision to foresee these things, and will cope with them.
The key selling point of Bluetooth is economic - it is low cost and low power, and that's exactly what's needed for things like headsets and consumer electronics. Price pressure is everything. The Bluetooth chip manufacturers are at the cutting edge with RF-on-chip technology - and the winners in this race will be those that can come up with a small-size, low-power and low-cost solution.
My cynical perspective is that Bluetooth will become the technology of the wireless age, and like Microsoft and desktop computing, it will be both an enabler and a hindrance, and be somewhat controversial.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
The links in the original post seems to be corrupted -- here they are again:
Can somebody fix the original?
---
"Where do you come from?"
Hi!