Nearby API - queuing of payloads










0















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




























    0















    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


























      0












      0








      0








      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 Dec 10 '18 at 8:21







      webaloman

















      asked Nov 15 '18 at 1:59









      webalomanwebaloman

      103212




      103212






















          2 Answers
          2






          active

          oldest

          votes


















          1














          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






























            0














            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',
              autoActivateHeartbeat: false,
              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









              1














              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



























                1














                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

























                  1












                  1








                  1







                  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 '18 at 17:39









                  Varun KapoorVarun Kapoor

                  1062




                  1062























                      0














                      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



























                        0














                        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

























                          0












                          0








                          0







                          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 '18 at 23:42









                          XlytheXlythe

                          69549




                          69549



























                              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.




                              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







                              這個網誌中的熱門文章

                              How to read a connectionString WITH PROVIDER in .NET Core?

                              Museum of Modern and Contemporary Art of Trento and Rovereto

                              In R, how to develop a multiplot heatmap.2 figure showing key labels successfully