It turns out that choosing which machine to connect to and how to connect are the most difficult parts of Bluetooth programming. In writing a server application, once the transport protocol and port number to listen on are chosen, building the rest of the application is essentially the same type of programming most network programmers are already accustomed to. A server application waiting for an incoming Bluetooth connection is conceptually the same as a server application waiting for an incoming Internet connection, and a client application attempting to establish an outbound connection appears the same whether it is using RFCOMM, L2CAP, TCP, or UDP.
Furthermore, once the connection has been established, the application is operating with the same guarantees, constraints, and error conditions as are encountered in Internet programming. Depending on the transport protocol chosen, packets may be dropped or delayed. Connections may be severed due to host or link failures. External factors such as congestion and interference may result in decreased quality of service. Due to these conceptual similarities, it is perfectly reasonable to treat Bluetooth programming of an established connection in exactly the same manner that as an established connections in Internet programming.