Nearby API - queuing of payloads











up vote
0
down vote

favorite












I have an use case where I am sending control data from AndroidThings device to an Android mobile phone - it is periodal reading of voltage 10 times a second, so every 100 millis.
But since this is Nearby API feature - concering sending payloads:




Senders use the sendPayload() method to send a Payload. This method can be invoked multiple times, but since we guarantee in-order delivery, the second Payload onwards will be queued for sending until the first Payload is done.




What happens in reality in my case is, based on the the fact that transmission speed varies, I am getting readings on the phone with delay that is increasing, simply queue gets bigger and bigger.



Any ideas how to overcome this ? Basically I don't need in-order delivery.
My first idea is to have some sort of confirmation of payload delivery and only after the confirmation of receipt the second payload should be sent to recipient.



Thanks for ideas



UPDATE:



STREAM type of payload is a perferct solution. If the InputStream transfers more than one set of readings (reading inlcude voltage, maxvoltage etc. altogether 32 bytes of data) then I use the skip method to skip to the very last readings.










share|improve this question




























    up vote
    0
    down vote

    favorite












    I have an use case where I am sending control data from AndroidThings device to an Android mobile phone - it is periodal reading of voltage 10 times a second, so every 100 millis.
    But since this is Nearby API feature - concering sending payloads:




    Senders use the sendPayload() method to send a Payload. This method can be invoked multiple times, but since we guarantee in-order delivery, the second Payload onwards will be queued for sending until the first Payload is done.




    What happens in reality in my case is, based on the the fact that transmission speed varies, I am getting readings on the phone with delay that is increasing, simply queue gets bigger and bigger.



    Any ideas how to overcome this ? Basically I don't need in-order delivery.
    My first idea is to have some sort of confirmation of payload delivery and only after the confirmation of receipt the second payload should be sent to recipient.



    Thanks for ideas



    UPDATE:



    STREAM type of payload is a perferct solution. If the InputStream transfers more than one set of readings (reading inlcude voltage, maxvoltage etc. altogether 32 bytes of data) then I use the skip method to skip to the very last readings.










    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I have an use case where I am sending control data from AndroidThings device to an Android mobile phone - it is periodal reading of voltage 10 times a second, so every 100 millis.
      But since this is Nearby API feature - concering sending payloads:




      Senders use the sendPayload() method to send a Payload. This method can be invoked multiple times, but since we guarantee in-order delivery, the second Payload onwards will be queued for sending until the first Payload is done.




      What happens in reality in my case is, based on the the fact that transmission speed varies, I am getting readings on the phone with delay that is increasing, simply queue gets bigger and bigger.



      Any ideas how to overcome this ? Basically I don't need in-order delivery.
      My first idea is to have some sort of confirmation of payload delivery and only after the confirmation of receipt the second payload should be sent to recipient.



      Thanks for ideas



      UPDATE:



      STREAM type of payload is a perferct solution. If the InputStream transfers more than one set of readings (reading inlcude voltage, maxvoltage etc. altogether 32 bytes of data) then I use the skip method to skip to the very last readings.










      share|improve this question















      I have an use case where I am sending control data from AndroidThings device to an Android mobile phone - it is periodal reading of voltage 10 times a second, so every 100 millis.
      But since this is Nearby API feature - concering sending payloads:




      Senders use the sendPayload() method to send a Payload. This method can be invoked multiple times, but since we guarantee in-order delivery, the second Payload onwards will be queued for sending until the first Payload is done.




      What happens in reality in my case is, based on the the fact that transmission speed varies, I am getting readings on the phone with delay that is increasing, simply queue gets bigger and bigger.



      Any ideas how to overcome this ? Basically I don't need in-order delivery.
      My first idea is to have some sort of confirmation of payload delivery and only after the confirmation of receipt the second payload should be sent to recipient.



      Thanks for ideas



      UPDATE:



      STREAM type of payload is a perferct solution. If the InputStream transfers more than one set of readings (reading inlcude voltage, maxvoltage etc. altogether 32 bytes of data) then I use the skip method to skip to the very last readings.







      google-nearby






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited yesterday

























      asked Nov 15 at 1:59









      webaloman

      98212




      98212
























          2 Answers
          2






          active

          oldest

          votes

















          up vote
          1
          down vote



          accepted










          For your use-case, I would recommend using a STREAM Payload, and then you can keep streaming your control data over that single Payload -- this is exactly one of the use-cases for which we created STREAM. :)






          share|improve this answer




























            up vote
            0
            down vote













            Yup, your first idea sounds like the right thing to do. There's no way to turn off in-order delivery of payloads inside Nearby Connections, so you'll have to handle dropping payloads yourself.



            I would build a class that caches the 'most recent voltage'. As you get new readings, this value will overwrite itself each time.



            private volatile Long mostRecentVoltage;

            public void updateVoltage(long voltage) {
            if (mostRecentVoltage != null) {
            Log.d(TAG, String.format("Dropping voltage %d due to poor network latency", mostRecentVoltage));
            }
            mostRecentVoltage = voltage;
            }


            Then add another piece of logic that'll grab the cached value every time the previous payload was successfully sent.



            @Nullable
            public Long getVoltage() {
            try {
            return mostRecentVoltage;
            } finally {
            mostRecentVoltage = null;
            }
            }





            share|improve this answer





















              Your Answer






              StackExchange.ifUsing("editor", function () {
              StackExchange.using("externalEditor", function () {
              StackExchange.using("snippets", function () {
              StackExchange.snippets.init();
              });
              });
              }, "code-snippets");

              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "1"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311364%2fnearby-api-queuing-of-payloads%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              1
              down vote



              accepted










              For your use-case, I would recommend using a STREAM Payload, and then you can keep streaming your control data over that single Payload -- this is exactly one of the use-cases for which we created STREAM. :)






              share|improve this answer

























                up vote
                1
                down vote



                accepted










                For your use-case, I would recommend using a STREAM Payload, and then you can keep streaming your control data over that single Payload -- this is exactly one of the use-cases for which we created STREAM. :)






                share|improve this answer























                  up vote
                  1
                  down vote



                  accepted







                  up vote
                  1
                  down vote



                  accepted






                  For your use-case, I would recommend using a STREAM Payload, and then you can keep streaming your control data over that single Payload -- this is exactly one of the use-cases for which we created STREAM. :)






                  share|improve this answer












                  For your use-case, I would recommend using a STREAM Payload, and then you can keep streaming your control data over that single Payload -- this is exactly one of the use-cases for which we created STREAM. :)







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 27 at 17:39









                  Varun Kapoor

                  1062




                  1062
























                      up vote
                      0
                      down vote













                      Yup, your first idea sounds like the right thing to do. There's no way to turn off in-order delivery of payloads inside Nearby Connections, so you'll have to handle dropping payloads yourself.



                      I would build a class that caches the 'most recent voltage'. As you get new readings, this value will overwrite itself each time.



                      private volatile Long mostRecentVoltage;

                      public void updateVoltage(long voltage) {
                      if (mostRecentVoltage != null) {
                      Log.d(TAG, String.format("Dropping voltage %d due to poor network latency", mostRecentVoltage));
                      }
                      mostRecentVoltage = voltage;
                      }


                      Then add another piece of logic that'll grab the cached value every time the previous payload was successfully sent.



                      @Nullable
                      public Long getVoltage() {
                      try {
                      return mostRecentVoltage;
                      } finally {
                      mostRecentVoltage = null;
                      }
                      }





                      share|improve this answer

























                        up vote
                        0
                        down vote













                        Yup, your first idea sounds like the right thing to do. There's no way to turn off in-order delivery of payloads inside Nearby Connections, so you'll have to handle dropping payloads yourself.



                        I would build a class that caches the 'most recent voltage'. As you get new readings, this value will overwrite itself each time.



                        private volatile Long mostRecentVoltage;

                        public void updateVoltage(long voltage) {
                        if (mostRecentVoltage != null) {
                        Log.d(TAG, String.format("Dropping voltage %d due to poor network latency", mostRecentVoltage));
                        }
                        mostRecentVoltage = voltage;
                        }


                        Then add another piece of logic that'll grab the cached value every time the previous payload was successfully sent.



                        @Nullable
                        public Long getVoltage() {
                        try {
                        return mostRecentVoltage;
                        } finally {
                        mostRecentVoltage = null;
                        }
                        }





                        share|improve this answer























                          up vote
                          0
                          down vote










                          up vote
                          0
                          down vote









                          Yup, your first idea sounds like the right thing to do. There's no way to turn off in-order delivery of payloads inside Nearby Connections, so you'll have to handle dropping payloads yourself.



                          I would build a class that caches the 'most recent voltage'. As you get new readings, this value will overwrite itself each time.



                          private volatile Long mostRecentVoltage;

                          public void updateVoltage(long voltage) {
                          if (mostRecentVoltage != null) {
                          Log.d(TAG, String.format("Dropping voltage %d due to poor network latency", mostRecentVoltage));
                          }
                          mostRecentVoltage = voltage;
                          }


                          Then add another piece of logic that'll grab the cached value every time the previous payload was successfully sent.



                          @Nullable
                          public Long getVoltage() {
                          try {
                          return mostRecentVoltage;
                          } finally {
                          mostRecentVoltage = null;
                          }
                          }





                          share|improve this answer












                          Yup, your first idea sounds like the right thing to do. There's no way to turn off in-order delivery of payloads inside Nearby Connections, so you'll have to handle dropping payloads yourself.



                          I would build a class that caches the 'most recent voltage'. As you get new readings, this value will overwrite itself each time.



                          private volatile Long mostRecentVoltage;

                          public void updateVoltage(long voltage) {
                          if (mostRecentVoltage != null) {
                          Log.d(TAG, String.format("Dropping voltage %d due to poor network latency", mostRecentVoltage));
                          }
                          mostRecentVoltage = voltage;
                          }


                          Then add another piece of logic that'll grab the cached value every time the previous payload was successfully sent.



                          @Nullable
                          public Long getVoltage() {
                          try {
                          return mostRecentVoltage;
                          } finally {
                          mostRecentVoltage = null;
                          }
                          }






                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 19 at 23:42









                          Xlythe

                          56038




                          56038






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311364%2fnearby-api-queuing-of-payloads%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              How to change which sound is reproduced for terminal bell?

                              Can I use Tabulator js library in my java Spring + Thymeleaf project?

                              Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents