B4J Question [SOLVED] How does FTP object of jNet library pick local IP address


Well-Known Member
Licensed User
I have a field PC with a network configuration as per this figure:


The real Ethernet adapter uses a lan cable to a 4G outdoor router with a static IP SIM in it - relatively expensive data plan.

The various wifi adapters connect over wifi to other 4G outdoor routers with floating IP SIMs - relatively inexpensive data plans.

The wifi adapters are "bonded" together via Speedify as per this figure:


I am running a B4J app that uses the FTP object of the jNet library to upload masses of .jpeg files to the AWS cloud.

I am using Speedify in the expectation it will effectively load balance over the multiple wifi adapters - I'm not really interested in Speedify's other capabilities.

Testing to date has resulted - somewhat magically to my untrained mind - in the B4J app always using the Speedify Virtual adapter - which is what I want.

That leaves the real Ethernet adapter free to simultaneously do other stuff - like run VNC (which needs a static IP) for management of the PC.

My worry is that I do not understand why my B4J app is always using Speedify - how and why does the FTP object do this?

Is it just as likely to pick the real Ethernet adapter on other occasions.

If there anyway to force the FTP object to always use Speedify?

Thanks in advance...


Well-Known Member
Licensed User
I think I may have found the answer, at least for Windows 10.

Look at:




It appears that in Windows 10 each network adapter has a "Interface metric" property - the first URL shows how to get to it and the second URL explains the significance of various values (specifically the 3rd table for Windows 10).

Quoting from the first URL:
On Windows 10, if you have a device with more than one network adapter (such as Ethernet and Wi-Fi), each interface receives a priority value automatically based on its network metric, which defines the primary connection that your device will use to send and receive networking traffic.

Normally this "interface metric" is set to "automatic metric" - i.e. the operating system decides what is the "primary connection".

But by using the above info you can manually override - or heavily enforce - what is the "primary connection".

So in my case I have set the real Ethernet adapter at 95, the real wifi adapters all at 90 and left the Speedify Virtual Adapter as "automatic metric".

The reason I have left the Speedify Virtual Adapter as "automatic metric" is it wouldn't let me change it - it wanted an IP address to be defined and at that point I backed off.

But seeing as it is using the real wifi adapters and none of their "automatic metric" values can be more than 85 (again table 3, second URL) then the Speedify Virtual Adapter should never have an "automatic metric" higher than 85. As this is less than the manual values of 90 and 95 I have forced on the real adapters it should mean that it is always the "primary connection".

I would be more than interested in any comments or counter views to the above...
Last edited:
Upvote 0


Well-Known Member
Licensed User
After discovering the stuff in post #3 I posted a question to Speedify support and have just received a response:
Speedify does not rely on the interface metric to route traffic over the VPN. It modifies the routing table to direct traffic over the VPN. I am not able to share all the specifics with you, but it is similar to the approach that OpenVPN uses.

So the above exercise was unnecessary apparently.

I'm becoming more impressed with Speedify - for one their support is real - not as good as B4X though :)
Last edited:
Upvote 0