Please help me understanding Bluetooth "socket"usage ...
-
As I said many times - I have been using that (reference) as very rudimentary Bluetooth tutorial. It has been copied many times and with no actual implementation AKA passing data in serial connection - from serial port to serial remote destination , preferably both ways... . The "connection" between serial source (file) is not implemented - the data is "hard co0ded" into local Bluetooth adapter = and that is why I am asking for "socket" help. I need to "extend" the conncetion from serial source - dynamic file - to remote Bluetooth device. The article is nice but plagiarized many times over and poorly disguised as open source -"tutorial" based on poorly documented "bluez" library. Besides - if you pay attenti0on to the title - I asked for help with using "socket". Thanks.
Member 14968771 wrote:
if you pay attenti0on to the title - I asked for help with using "socket".
Well this is what you actually asked:
Member 14968771 wrote:
I am , rater naively, looking for (C/C++ no command scripts , please ) documented / commented example on how to implement Bluetooth in Linux, preferably skipping "bluez".
And that was the best example Google found for me. I have not been able to test it for you as I don't have the bluez library. But if you want to know how to use sockets directly then Google will find plenty of sample code that shows a client server implementation, e.g socket c programming - Google Search[^]. But you will still need to have a good understanding of the bluetooth transport protocol to implement it; that is why people use ready made libraries.
-
After RTFM I am no close in understanding how to actually use / implement "socket" in Linux / Bluetooth. I have two examples - one what appears to be the original usage of "bluez" Library and another... This one "builds' socket from "dev-id" sock = hci_open_dev( dev_id ); however the other one "skips" hci-open-dev' BUT expect few parameters... some of them are " (Bluetooth ) automatic" if some of them are "null". // allocate server socket server_socket = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); if(server_socket < 0 ) { text = "FAILED allocate server socket "; text += Q_FUNC_INFO; text += " @ line "; text += QString::number(__LINE__); qDebug() << text; } else { I am , rater naively, looking for (C/C++ no command scripts , please ) documented / commented example on how to implement Bluetooth in Linux, preferably skipping "bluez".
"Bluez" is the "official Linux Bluetooth stack". Your resistance to it simply means you will continue to flail about indefinitely. [https://www.researchgate.net/publication/345032366\_Bluetooth\_Stack\_and\_how\_Linux\_OS\_handles\_it#pf1f\](https://www.researchgate.net/publication/345032366\_Bluetooth\_Stack\_and\_how\_Linux\_OS\_handles\_it#pf1f)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
After RTFM I am no close in understanding how to actually use / implement "socket" in Linux / Bluetooth. I have two examples - one what appears to be the original usage of "bluez" Library and another... This one "builds' socket from "dev-id" sock = hci_open_dev( dev_id ); however the other one "skips" hci-open-dev' BUT expect few parameters... some of them are " (Bluetooth ) automatic" if some of them are "null". // allocate server socket server_socket = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); if(server_socket < 0 ) { text = "FAILED allocate server socket "; text += Q_FUNC_INFO; text += " @ line "; text += QString::number(__LINE__); qDebug() << text; } else { I am , rater naively, looking for (C/C++ no command scripts , please ) documented / commented example on how to implement Bluetooth in Linux, preferably skipping "bluez".
-
Member 14968771 wrote:
Linux, preferably skipping "bluez"
Even if you don't want to use it you can still look at it to see how they do it. The license it has means you can do anything you want with it.
Kindly allow me to "get back to socket code"... Here is my socket code
{ // socket code block // allocate server socket server\_socket = socket(AF\_BLUETOOTH, SOCK\_STREAM, BTPROTO\_RFCOMM); if(server\_socket < 0 ) { text = "FAILED allocate server socket "; text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; } else { #ifdef C\_CODE\_TRACE text = "VERIFY SUCCESS OK allocated extended server socket "; text += QString::number(server\_socket); text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; #endif } }// socket code block return 0;' 'here is the debug output: '
<"MainWindow_C_CODE_FORM::MainWindow_C_CODE_FORM(QWidget *)10"
"add it as subwindow "
"int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 211"
"VERIFY SUCCESS OK allocated extended server socket 26int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 234"/pre>This is what I am following :
/* Create a new socket of type TYPE in domain DOMAIN, using
protocol PROTOCOL. If PROTOCOL is zero, one is chosen automatically.
Returns a file descriptor for the new socket, or -1 for errors. */
extern int socket (int __domain, int __type, int __protocol) __THROW;
/* Create two new sockets, of type TYPE in domain DOMAIN and using
protocol PROTOCOL, which are connected to each other, and put file
descriptors for them in FDS[0] and FDS[1]. If PROTOCOL is zero,
one will be chosen automatically. Returns 0 on success, -1 for errors. */
extern int socketpair (int __domain, int __type, int __protocol,int \_\_fds\[2\]) \_\_THROW;/* Give the socket FD the local address ADDR (which is LEN bytes long). */
extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)
__THROW;/* Put the local address of FD into *ADDR and its length in *LEN. */
extern int getsockname (int __fd, __SOCKADDR_ARG __addr,
socklen_t *__restrict __len) __THROW;/* Open a connection on socket FD to peer at ADDR (which LEN bytes long).
For connectionless socket types, just set the default address to send to
and the only address from which to accept transmissions.
Return 0 on success, -1 for errors.This function i
-
Kindly allow me to "get back to socket code"... Here is my socket code
{ // socket code block // allocate server socket server\_socket = socket(AF\_BLUETOOTH, SOCK\_STREAM, BTPROTO\_RFCOMM); if(server\_socket < 0 ) { text = "FAILED allocate server socket "; text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; } else { #ifdef C\_CODE\_TRACE text = "VERIFY SUCCESS OK allocated extended server socket "; text += QString::number(server\_socket); text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; #endif } }// socket code block return 0;' 'here is the debug output: '
<"MainWindow_C_CODE_FORM::MainWindow_C_CODE_FORM(QWidget *)10"
"add it as subwindow "
"int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 211"
"VERIFY SUCCESS OK allocated extended server socket 26int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 234"/pre>This is what I am following :
/* Create a new socket of type TYPE in domain DOMAIN, using
protocol PROTOCOL. If PROTOCOL is zero, one is chosen automatically.
Returns a file descriptor for the new socket, or -1 for errors. */
extern int socket (int __domain, int __type, int __protocol) __THROW;
/* Create two new sockets, of type TYPE in domain DOMAIN and using
protocol PROTOCOL, which are connected to each other, and put file
descriptors for them in FDS[0] and FDS[1]. If PROTOCOL is zero,
one will be chosen automatically. Returns 0 on success, -1 for errors. */
extern int socketpair (int __domain, int __type, int __protocol,int \_\_fds\[2\]) \_\_THROW;/* Give the socket FD the local address ADDR (which is LEN bytes long). */
extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)
__THROW;/* Put the local address of FD into *ADDR and its length in *LEN. */
extern int getsockname (int __fd, __SOCKADDR_ARG __addr,
socklen_t *__restrict __len) __THROW;/* Open a connection on socket FD to peer at ADDR (which LEN bytes long).
For connectionless socket types, just set the default address to send to
and the only address from which to accept transmissions.
Return 0 on success, -1 for errors.This function i
Member 14968771 wrote:
How do I implement "Linux socket " for same ?
You do what I suggested yesterday and implement the bluetooth protocol in your code. The document I gave you the link for gives example code. But if that is not enough you need to study the bluetooth protocol, and Google will find plenty of references for you.
-
Kindly allow me to "get back to socket code"... Here is my socket code
{ // socket code block // allocate server socket server\_socket = socket(AF\_BLUETOOTH, SOCK\_STREAM, BTPROTO\_RFCOMM); if(server\_socket < 0 ) { text = "FAILED allocate server socket "; text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; } else { #ifdef C\_CODE\_TRACE text = "VERIFY SUCCESS OK allocated extended server socket "; text += QString::number(server\_socket); text += Q\_FUNC\_INFO; text += " @ line "; text += QString::number(\_\_LINE\_\_); qDebug() << text; #endif } }// socket code block return 0;' 'here is the debug output: '
<"MainWindow_C_CODE_FORM::MainWindow_C_CODE_FORM(QWidget *)10"
"add it as subwindow "
"int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 211"
"VERIFY SUCCESS OK allocated extended server socket 26int MainWindow_C_CODE_FORM::C_CODE_Scanner() @ line 234"/pre>This is what I am following :
/* Create a new socket of type TYPE in domain DOMAIN, using
protocol PROTOCOL. If PROTOCOL is zero, one is chosen automatically.
Returns a file descriptor for the new socket, or -1 for errors. */
extern int socket (int __domain, int __type, int __protocol) __THROW;
/* Create two new sockets, of type TYPE in domain DOMAIN and using
protocol PROTOCOL, which are connected to each other, and put file
descriptors for them in FDS[0] and FDS[1]. If PROTOCOL is zero,
one will be chosen automatically. Returns 0 on success, -1 for errors. */
extern int socketpair (int __domain, int __type, int __protocol,int \_\_fds\[2\]) \_\_THROW;/* Give the socket FD the local address ADDR (which is LEN bytes long). */
extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)
__THROW;/* Put the local address of FD into *ADDR and its length in *LEN. */
extern int getsockname (int __fd, __SOCKADDR_ARG __addr,
socklen_t *__restrict __len) __THROW;/* Open a connection on socket FD to peer at ADDR (which LEN bytes long).
For connectionless socket types, just set the default address to send to
and the only address from which to accept transmissions.
Return 0 on success, -1 for errors.This function i
Member 14968771 wrote:
How do I implement "Linux socket " for same ?
Myself I have no idea. But if it was me and I could not use the other library then, as I already stated, I would look at the source code for the library because the license specifically allows that. That would give me ideas to implement it on my own.
-
Member 14968771 wrote:
How do I implement "Linux socket " for same ?
Myself I have no idea. But if it was me and I could not use the other library then, as I already stated, I would look at the source code for the library because the license specifically allows that. That would give me ideas to implement it on my own.
Perhaps I need to dummy down my post The often mentioned "bluez" article basically 1. get "device_id" without explaining what is "device id" 2. then it uses such "device id" to build / create ? "assign" / allocate ( the user is free to pick term to his liking) Then there is a plain / direct way to
build / create ? "assign" / allocate
socket WITHOUT using intermediate device id. My question is what is / are , if any , real differences between starting with unspecified "device id" and just using "socket" function? Or to put it differently - how does "socket" ( single "connection point ", not a real connection ) fits into the "replacing RS232 with Bluetooth"? What is next ?? PS I can get "local adapter NAME" from so far identified , either way , "socket"... It has been suggested to retrieve local adapter after CONNECTION TO THE REMOTE DEVICE -- how ?? the local adapter is the one scanning (*hci unquiry") for connection in the first place...
-
Perhaps I need to dummy down my post The often mentioned "bluez" article basically 1. get "device_id" without explaining what is "device id" 2. then it uses such "device id" to build / create ? "assign" / allocate ( the user is free to pick term to his liking) Then there is a plain / direct way to
build / create ? "assign" / allocate
socket WITHOUT using intermediate device id. My question is what is / are , if any , real differences between starting with unspecified "device id" and just using "socket" function? Or to put it differently - how does "socket" ( single "connection point ", not a real connection ) fits into the "replacing RS232 with Bluetooth"? What is next ?? PS I can get "local adapter NAME" from so far identified , either way , "socket"... It has been suggested to retrieve local adapter after CONNECTION TO THE REMOTE DEVICE -- how ?? the local adapter is the one scanning (*hci unquiry") for connection in the first place...
You seem to be struggking with some basic concepts. A device_id is simply an identifier that is returned by the bluetooth driver in the kernel. The kernel code uses this id to acces a specific connection (socket etc.) between devices. So every time you call a library function, you pass it the device_id so the driver code knows which connection you are referring to. I use the analogy of a telphone number, if you pass your telephone number to your mobile service provider, it always knows where to send messages. If you want to bypass the device_id and use a plain socket (which is conceptually the same thing as described above) then that is fine. But as we keep saying, that means you have to write the code to actually use the bluetooth protocol over the connection that the socket makes with a remote device. Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model. But ultimately all your questions are asking for more information than there is space for in a forum such as this. The only way to get a good understanding of what you are trying to do (which remains something of a mystery) is to do a lot of research. The internet has hundreds of papers that detail networking in general and the various specific protocols, so that is where you need to go. The link I gave you three days ago gives some good details (although abridged) on this whole subject. I strongly advise you to study it carefully, as it answers at least most of your questions.
-
You seem to be struggking with some basic concepts. A device_id is simply an identifier that is returned by the bluetooth driver in the kernel. The kernel code uses this id to acces a specific connection (socket etc.) between devices. So every time you call a library function, you pass it the device_id so the driver code knows which connection you are referring to. I use the analogy of a telphone number, if you pass your telephone number to your mobile service provider, it always knows where to send messages. If you want to bypass the device_id and use a plain socket (which is conceptually the same thing as described above) then that is fine. But as we keep saying, that means you have to write the code to actually use the bluetooth protocol over the connection that the socket makes with a remote device. Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model. But ultimately all your questions are asking for more information than there is space for in a forum such as this. The only way to get a good understanding of what you are trying to do (which remains something of a mystery) is to do a lot of research. The internet has hundreds of papers that detail networking in general and the various specific protocols, so that is where you need to go. The link I gave you three days ago gives some good details (although abridged) on this whole subject. I strongly advise you to study it carefully, as it answers at least most of your questions.
Richard MacCutchan wrote:
. Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model.
Any protocol that makes a distinction between higher and lower levels can be said to 'use the ISO/OSI model'. Or so it seems. I never saw any protocol with at least some higher/lower distinction (even morse can be said to have a 'higher' layer that is the di and dahs, and a 'lower' layer that is the generating of the carrier wave of the appropriate frequency. I came into Bluetooth from an OSI angle, and started searching for service definitions according to OSI principles, protocol definitions according to OSI principles, and most important, a separation of these, according to OSI principles. I started searching for layer independence, so that the same service interface (at each level) could be implemented by alternate lower layer protocols (and lower service interfaces). Nothing like that exists. I started searching for protocol events and service interface events suitable for building a state machine in agreement with the standard OSI state machines. You'll never find that. The Bluetooth designers have even blurred the event concept: An event is certainly not atomic, but may include several packet exchanges. Protocol-wise, Bluetooth is one big crow's nest. To quote Ted Nelson: Everything is deeply intertwingled. BT is a world of its own. Sure can be split into levels, just like any other protocol, but using the term 'layers' for these levels doesn't make it OSI. BT service and protocol definitions have no relationship at all to 'true' OSI service/protocol layers.
-
Richard MacCutchan wrote:
. Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model.
Any protocol that makes a distinction between higher and lower levels can be said to 'use the ISO/OSI model'. Or so it seems. I never saw any protocol with at least some higher/lower distinction (even morse can be said to have a 'higher' layer that is the di and dahs, and a 'lower' layer that is the generating of the carrier wave of the appropriate frequency. I came into Bluetooth from an OSI angle, and started searching for service definitions according to OSI principles, protocol definitions according to OSI principles, and most important, a separation of these, according to OSI principles. I started searching for layer independence, so that the same service interface (at each level) could be implemented by alternate lower layer protocols (and lower service interfaces). Nothing like that exists. I started searching for protocol events and service interface events suitable for building a state machine in agreement with the standard OSI state machines. You'll never find that. The Bluetooth designers have even blurred the event concept: An event is certainly not atomic, but may include several packet exchanges. Protocol-wise, Bluetooth is one big crow's nest. To quote Ted Nelson: Everything is deeply intertwingled. BT is a world of its own. Sure can be split into levels, just like any other protocol, but using the term 'layers' for these levels doesn't make it OSI. BT service and protocol definitions have no relationship at all to 'true' OSI service/protocol layers.