You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using this inside a Capacitor hybrid mobile app, which uses TCP sockets to communicate with a proprietary device using a local WiFi network. I used the original blocshop version of this, and then a custom fork of this from somewhere else that a friend of mine helped me out with. since I was updating a bunch of other dependencies in this project, I decided to try the latest current version again, but I'm running into inexplicable issues.
one function of my app "scans" the current WiFi network (tl;dr: get current host subnet, calculate all possible IP addresses, try a TCP socket on 5001 for each one), using p-queue to limit the number of concurrent socket connection attempts.
when I have the concurrency limit set to anything other than 1, it my concurrency limiter shoots through all 252 addresses (everything except x.x.x.0 and the current host) in about 5 seconds, finding the one and only test device on my network maybe 1 out of every 20 attempts.
on the other hand, when I limit the concurrency to exactly 1 then each test takes about one or two seconds, and it does always find my test device.. but this takes 2 or 3 minutes to complete. similarly, once I know the IP address, I can open a new TCP socket to that specific address directly with no issues at all.
NOTE: I have not tested this "scan" logic on iOS yet, but previous versions of my app did work as expected on both mobile platforms.. alas, since I don't have a Mac, my only path to that is build in CodeMagic and distribute through TestFlight, so my local testing is all done using Android, both in emulators and physical devices.
@kitolog any chance you could perhaps shed some light on this? should this plugin be able to handle multiple concurrent TCP sockets? could having one connection attempt fail possibly spill over and affect the next and/or a concurrent connection attempt?
The text was updated successfully, but these errors were encountered:
I'm using this inside a Capacitor hybrid mobile app, which uses TCP sockets to communicate with a proprietary device using a local WiFi network. I used the original
blocshop
version of this, and then a custom fork of this from somewhere else that a friend of mine helped me out with. since I was updating a bunch of other dependencies in this project, I decided to try the latest current version again, but I'm running into inexplicable issues.one function of my app "scans" the current WiFi network (tl;dr: get current host subnet, calculate all possible IP addresses, try a TCP socket on
5001
for each one), usingp-queue
to limit the number of concurrent socket connection attempts.when I have the concurrency limit set to anything other than
1
, it my concurrency limiter shoots through all 252 addresses (everything exceptx.x.x.0
and the current host) in about 5 seconds, finding the one and only test device on my network maybe 1 out of every 20 attempts.on the other hand, when I limit the concurrency to exactly
1
then each test takes about one or two seconds, and it does always find my test device.. but this takes 2 or 3 minutes to complete. similarly, once I know the IP address, I can open a new TCP socket to that specific address directly with no issues at all.NOTE: I have not tested this "scan" logic on iOS yet, but previous versions of my app did work as expected on both mobile platforms.. alas, since I don't have a Mac, my only path to that is build in CodeMagic and distribute through TestFlight, so my local testing is all done using Android, both in emulators and physical devices.
@kitolog any chance you could perhaps shed some light on this? should this plugin be able to handle multiple concurrent TCP sockets? could having one connection attempt fail possibly spill over and affect the next and/or a concurrent connection attempt?
The text was updated successfully, but these errors were encountered: