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

Discussion in 'B4J Questions' started by JackKirk, Feb 1, 2019.

  1. JackKirk

    JackKirk 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...
  2. Erel

    Erel Administrator Staff Member Licensed User

    I don't think so. It just asks to OS for a socket and use whichever one it received.
  3. JackKirk

    JackKirk 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:
    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: Feb 2, 2019
    DonManfred likes this.
  4. JackKirk

    JackKirk 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:
    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: Feb 5, 2019
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice