• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 67 subscribers
  • Views 1385 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104112
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best Practise with Authorized Read/Writes

Locky

I am writing a custom Service. I need to catch when a Client tries to Read certain characteristics or Write to other characteristics. What is the best practice for Authorizing the Read or Write? Done as soon as the event is caught by the application, or can I perform this after a series of callback functions are performed to verify the handle and value? I certain wouldn't want to create a race condition nor bottleneck for authorizing incoming Read or Write. Especially during an initialization process when many read/writes occur.

Thanks guys.

Parents
  • 0

    There are a few spec limitations you need to keep in mind here:

    1. You can only have one outstanding request per protocol (for ATT, e.g read or write req).
    2. You have to respond to an ATT request within 30s.
    3. If a request times out, all traffic on that protocol (e.g. ATT) is prohibited for the duration of that physical connection.

    Depending on your connection parameters and your desired throughput, you can do anything as long as you know about those limitations. If you want higher throughput, you will have to minimize the time between the authorization event and the response, but you can do processing for quite some time before you get close to timing out. I don't think you are risking any race conditions in here due to the first point. The peer cannot send a read request until the write request is responded to.

Reply
  • 0

    There are a few spec limitations you need to keep in mind here:

    1. You can only have one outstanding request per protocol (for ATT, e.g read or write req).
    2. You have to respond to an ATT request within 30s.
    3. If a request times out, all traffic on that protocol (e.g. ATT) is prohibited for the duration of that physical connection.

    Depending on your connection parameters and your desired throughput, you can do anything as long as you know about those limitations. If you want higher throughput, you will have to minimize the time between the authorization event and the response, but you can do processing for quite some time before you get close to timing out. I don't think you are risking any race conditions in here due to the first point. The peer cannot send a read request until the write request is responded to.

Children
No Data
Related