Help me to understand "hosts" file and socket communication via bluetooth

[Lost User]

The loopback address is always 127.0.0.1, as shown in your hosts files. 1. You bind sockets to IP addresses, not names. So use the appropriate system call to find the correct local address for the name you wish to bind. 2. Use the first name in the hosts file. Multiple names just provide aliases for the address. 3. Not sure what you mean. Loopback by definition is local to the hardware on which the code is running. 4. The client should connect to the server's public address. That is to say, when the server sets up a listening socket, the client needs to know the server's listening address. In internet terms that would be the address found by using DNS lookups. In your tests you just need to hardcode the address in the client code. 5. see 4. 6. The other IP6 names are (probably) use for broadcast messages. Check the relevant RFC document for details.

[Vaclav_]

Thanks Richard. I need to keep this short, but Like you to know you are no being ignored. I do understand the 127.0.0.1 as loop back IP . I am still not sure when IP is "internal protocol" and when Internet protocol. I take it 127.0.0.1 is an "internal " "IP" address - singular. I have the "conversion from "nost" name to such IP address done. So far it looks as I have to have TWO sockets - one as "plain network" (with loopback 127.0.0.1) and the other as an addition of "RF communication " for future full usage of bluetooth. I have the "network" socket figured out and working on the RF socket. I assume they have to be "tied together" somehow. As far as "remote loopback " goes - such "feature is part of RS232 / EIA standard allowing the originator of the connection to set the receiving end to "remote loop back" to pass the data from the RS232 hardware back to sender without sending it to the attached hardware. That way the actual transmission path is used both ways without need to communicate to remote system. Perhaps it can be done by controlling the "RF socket" connection itself. But later. Back to entertain visiting grand kids. Sorry.

[Vaclav_]

Update Start with The “server” ( local PC) allocates a “socket” with parameters s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); and is set ( waits ) to receive connection from “client”. It is unclear , but logical that “client terminal “ should be specified - perhaps “client (host) bluetooth address – array of six entries should be entered somewhere – as a “remote address”. I am using term “terminal X address “ to get away from confusing usage of “address” which can be IP (generic network) or bluetooth address. So far the term “host” is associated with IP name / address and is really not specific to client or server. The bluetooth address seems to have no relations to IP address. Then The “client” (Rpi) software allocates a “socket” with parameters socket_descriptor_local = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); the “client” - (Rpi ) software originates connection to server ( connect to server bluetooth terminal address ) when data is ready to be passed onto “server” . For now I am passing simple message(s) only. It is also unclear how / where to specify “client terminal”. Currently I have two bluetooth hardware (USB) of different class connected. I do not see how "socket" cares about bluetooth class. I managed to run both software and received expected errors. Like to know WHO , not why, actually generates the "connection refused" - logically it should came from "connecting to RECEIVING terminal" , but I am not so sure how to identify that.

[Lost User]

The sequence should be something like:

To accept connections, the following steps are performed by the server side:

1. A socket is created with socket(2).

2. The socket is bound to a local address using bind(2), so that
   other sockets may be connect(2)ed to it.

3. A willingness to accept incoming connections and a queue
   limit for incoming connections are specified with listen().

4. Connections are accepted with accept(2).

as described at listen(2) - Linux manual page[^]. The client then connects by the following:

Creates the socket
Calls bind to bind the socket to the address of the server
Calls connect
starts sending messages

as described at bind(2) - Linux manual page[^]. I am not sure what special rules are needed when connecting via Bluetooth.

[Vaclav_]

Yes, that is generally my understanding of "how to". Sure makes using socket clearer then working with "HCI". It seems that passing the parameters to "socket" call , especially the DOMAIN and PROTOCOL "bypasses" the "bind" call. I need to work on that. But I got the basic doing expected stuff. Addendum How is this for laymen "definitions "? socket is "high level layer" - overall manager of I/O . bind attaches such socket to "local host" (address) - IP network in general , bluetooth address as option of general. connect attaches such socket via "transmission patch " to "remote" hardware / host , again generally to network (using IP address) , bluetoooth as network specific option using bluetooth address.

[Vaclav_]

I guess I have to establish "my model" first and use appropriate terminology. The objective is to display data processed on "embedded hardware" ( Raspberry Pi ) on PC. Hence (per attached note ) "Client (RPi ) requests a service ( display data passed to it ) from server." " TCP/IP enables peer-to-peer communication." Is very generic term used , however "peer-to- peer" is little misleading since it implies , to me , an equal function of each end of communication path - which "client / server " is NOT. TCP/IP is ONE part of actual implementation of the "transmission path " ( a generic term of describing the actuall communication path) - in this case I have TCP/IP and Bluetoooth RF participating in the "transmission path ". So in terminology of "communication " terms - I have a source - client - RPi communication / transmission path - TCP/IP and RF destination - server For simplicity I am going use SINGLE socket (DONE!) and the actaull communication - from source to destination can be also looked as "simplex" communication. The actaull passing of information between terminal points ( source / destination ) can be reversed. So much for theory. I am still trying to decipher the INDIVIDUAL function of parameters passed to "socket" Mainly the functions of DOMAIN parameter - either AF_x (Address family) or PF_x (Protocol family). I am unable to find decent definition of "AF_BLUETOOTH" DOMAIN parameter. (Time to find source code for "socket" function ) The puzzling part is PROTOCOL parameter by itself and its interaction with DOMAIN and TYPE.

The Client-Server Model

TCP/IP enables peer-to-peer communication.

Computers can cooperate as equals or in any desired way.

Most distributed applications have special roles.  For example:

    Server waits for a client request.

    Client requests a service from server.

[Lost User]

There are plenty of samples around the internet that contain the source code of a simple socket program. The key being that it shows the sequence of events for both server and client. Adapting such samples to your own requirements is a fairly simple process. I do not have a current copy but I used one in the past in my professional life.

[Vaclav_]

SUCCESS ! Richard, thanks for your support. Learn few things about what now looks as easy coding. Managed to pass text message from client to server via bluetooth using socket with these parameters on BOTH ends: s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); However, not home yet. Some “behind the scenes" needs investigating. Given up on local loopback test for now. The complier complains about this assignment, loc_addr.rc_bdaddr = *BDADDR_ANY; but the application works as expected when the loc_addr.rc_bdaddr is NOT assigned, loc_addr.rc_family = AF_BLUETOOTH; loc_addr.rc_bdaddr = *BDADDR_ANY; loc_addr.rc_channel = (uint8_t) 1; In file included from ../src/RPI_BT_SERVER.cpp:54:0: ../src/RPI_BT_SERVER.cpp: In function ‘int main()’: ../src/RPI_BT_SERVER.cpp:133:26: error: taking address of temporary [-fpermissive] loc_addr.rc_bdaddr = *BDADDR_ANY; BTW taken form RFCOMM example, like to know what is the reason for the "temporary" note.

[Lost User]

See C/C++ Warning: address of temporary with BDADDR_ANY Bluetooth library - Stack Overflow[^]

[Vaclav_]

Thanks. Interestingly the simplest answer has no rating on site where rating the post is THE OBJECTIVE. .