From owner-freebsd-bluetooth@FreeBSD.ORG Thu Aug 23 08:59:23 2007 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E5D16A418 for ; Thu, 23 Aug 2007 08:59:23 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0125C13C49D for ; Thu, 23 Aug 2007 08:59:22 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-19-209.net-htp.de [89.182.19.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id 17BF3A44529; Thu, 23 Aug 2007 10:56:24 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: "Maksim Yevmenkin" Date: Thu, 23 Aug 2007 10:59:17 +0200 User-Agent: KMail/1.9.7 References: <200708211228.02044.wundram@beenic.net> <1187726992.986273.1438.nullmailer@galant.ukfsn.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708231059.19779.wundram@beenic.net> Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: Binding RFCOMM sockets X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 08:59:23 -0000 Am Mittwoch 22 August 2007 23:21:51 schrieb Maksim Yevmenkin: > On 8/21/07, Iain Hibbert wrote: > > nor in NetBSD - out of interest though, what is this server trying to > > achieve? It does not seem especially useful to listen on 'any' channel, > > given the way that bluetooth service discovery works.. > > well, the idea, imo, is when a server binds to 'any' channel (or psm), > the kernel will automatically assign first available one. next, the > application calls getsockname(2) to obtain the actual channel (or psm) > that was assigned by the kernel and registers that channel (or psm) > with sdp. > > this simplifies resource (i.e. channel or psm) management when > multiple applications are trying to provide multiple services at the > same time. basically you do not have to worry about assigning channels > (or psm's) by hand. This is exactly what I had in mind. Generally, what I'm currently building is an OBEX service framework which depending on the channel the remote application connects to should offer differing kinds of backend services. As the services themselves are fairly independent, I generally found the idea to have the kernel decide which channel to use for a specific was pretty much similar to what the portmapper does for TCP/IP, where a listening socket is bound if it wasn't on the listen command, and you can then retrieve the local address using getsockname() to register that port with the portmapper. Anyway, as you said you'd accept a patch from me, I'm currently trying to hack this into my 6.2-STABLE. I'll be able to tell you whether I'll manage to get this working by the end of the weekend; (FreeBSD) kernel-programming is utterly new for me. ;-) -- Heiko Wundram Product & Application Development