0

I have an Android app with an Indy TIdUDPServer component that is receiving data packets over a wireless network. It appears that Android phones periodically tie up the network for parts of a second, causing my server to miss packets (please do not comment on UDP vs TCP vs Tethering built in to RAD Studio).

I want to know - can I set the priority of my program, and/or the separate thread of the TIdUDPServer component, to a higher priority such that the bloatware on the phone doesn't keep getting in my way?

If so, I would appreciate an example.

For reference, I found this:

Changing thread priority doesn't have an effect

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
rebible
  • 99
  • 6
  • Did you check with a network sniffer if the lost packets are even reaching the phone at all? UDP can lose packets on the network, but if they arrive at the device they are usually discarded only if the socket's receive buffer is fully, otherwise they are buffered until you read them. Even if the phone is momentarily busy, packets should not get discarded unless the sender is sending much faster than you are able to read. You might try simply increasing the size of the socket's receive buffer using `TIdUDPServer.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVBUF, BufferSize)` – Remy Lebeau Sep 09 '17 at 01:03
  • If I run a windows machine next to the android.. the windows machine doesn't miss any packets. If the main thread is delayed because of slow screen writes everything is buffered presumably by Idupserver's buffer and it still operates only several seconds behind.. If I kill android background services like com.lg.bnr and messages everything is happy.. android is upset because there is no internet and keeps pinging out on the wifi,, why this would affect me I don't know.. but if again if I kill background services everything is fine... Not easy to do,, priority would be easier thanks – rebible Sep 09 '17 at 21:26
  • wndows machine connection might be better on wifi than android,, but it has to do with what android is doing on wifi outside of tiudp – rebible Sep 09 '17 at 21:27
  • I tried: IdUDPServer1.ThreadClass.Current.Suspend; IdUDPServer1.ThreadClass.Current.Priority:=tphigher; IdUDPServer1.ThreadClass.Current.resume; It generates socket error 111. – rebible Sep 14 '17 at 18:24
  • I have sniffed and definitely determined that the other android process such as finding the internet, trying to sync,,,etc. are stepping on top of the udp read process for a second or more. – rebible Sep 14 '17 at 18:26
  • You can't use the `ThreadClass` property that way. That property is used to let the app specify the desired `TIdUDPListenerThread`-derived class type for the server to use when creating its internal listening threads. Besides, `Current` (which doesn't exist, did you mean `CurrentThread`?) refers to the **calling** thread, not the listening threads. Suspending the thread that uses the server would be very bad, and setting the `Priority` of the *current* thread has no effect on the listening threads. – Remy Lebeau Sep 14 '17 at 18:34
  • To do what you are attempting, you could try creating a new class that derives from `TIdUDPListenerThread` and have its constructor set its `Priority` as desired, then assign that class type to the `ThreadClass` property before activating the server. However, on systems other than Windows and OSX, the server might try to force each thread's `Priority` to `tpListener` after constructing the thread. So, you may have to loop through the server's internal `FListenerThreads` list of thread objects to access their `Priority` property after the server has been activated – Remy Lebeau Sep 14 '17 at 18:36
  • is it possible to get the flistenerThreads android id so that you can use a direct android api call to set the priority? see ( https://stackoverflow.com/questions/9019137/changing-thread-priority-doesnt-have-an-effect).. from looking at tthread class is doesn't appear to me that the rtl is going to let you change the priority on an android system? – rebible Sep 15 '17 at 22:31
  • `FListenerThreads` is not a thread, it is a `TThreadList` of thread objects. You have to loop through the list to access the individual threads (1 for each `Bindings` item). And if you look at that other question more carefully, the problem was that the asker was using the wrong thread ID to set/query the priority, not that Android was blocking the new priority setting. `TThread` has `ID` and `Priority` properties, and they are implemented on Android. – Remy Lebeau Sep 16 '17 at 00:12

0 Answers0