Hi Luiz & Marcel, >>> ATT is a really simple protocol in this regard. >> >> It is simple, but it is also not structured. Opcode numbers have no higher meaning. They are just numbers. That why having a table of known opcodes and its semantics might be the simplest way. Sure. At least for requests, responses, and indications/notifications we can have a table. For commands, you can actually check if the command bit of the opcode has been set; in that regard the opcodes do have some higher meaning: they do encode whether or not the operation should be signed and whether or not they are commands. Then again, the spec does define specifically which opcodes should have those bits set. Eitherway, I will make it so that the semantic meaning of opcodes is more explicitly checked in the source file. >>> Absolutely. Let me know if this has convinced you. So my idea is to >>> have a bt_att_send and bt_att_send_without_rsp. I originally had a >>> single bt_att_send for all opcodes, but Luiz brought up the fact that >>> having a one for all function leads to some inconsistencies, such as >>> cases where a callback is passed along with an opcode that doesn't >>> expect a response. Personally I don't think this is such a problem as >>> long as the API is well documented. >> >> Right now as said above, just having bt_att_send seems enough. Start with that and see how it goes. Add an extra simpler helper that utilizes bt_att_send with an empty callback is dead simple. We can worry about that later. So, basically what I had earlier, with more explicit handling of opcode semantics instead of somewhat vague handlers? >> In case of MGMT perhaps it was different because there you don't >> actually have responses but actual requests that needs to be >> acknowledged before the next request can be sent out. > > Actually mgmt with calling write directly caused a bunch of issues. We are not doing that anymore. We nicely queue > everything so that orders actually become predictable. Well this is also true for ATT. I.e. a client is not supposed to send a second request before it has received a response to a previous request on the same connection, hence they have to go through two queues: a write queue waiting for POLLOUT, and a pending queue while waiting for the response from the remote device, where the pending queue bars any more requests from getting added to the write queue. Outgoing indications will also go through the same queues. Commands and notifications, on the other hand, skip the pending queue and can go straight to the write queue. The way I ended up implementing this involved having separate queues for requests, responses, commands, notifications, and indications, but I think that's overkill. We really just need a "sequential" queue, to queue requests and indications and a "non-sequential" queue for commands/notifications. In the former case, I think it's fine to use the same queue for indications and requests, since indications are only sent from servers and requests are only sent from clients, and afaik you can't have both ends of the same ATT connection be simultaneously in peripheral and central roles, though I may be wrong. At least this is why iOS (& Android afaik) seem to expose a different LE random address for each app that implements a GATT server. -Arman -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
