View Single Post
  #1  
Old April 30th 20, 10:48 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,comp.mobile.android
Arlen Holder[_7_]
external usenet poster
 
Posts: 141
Default Why would SMB seem to be more reliable than WebDav or FTP or KDEConnect, etc., for Wi-Fi "network connections" between Android & Windows?

Why would SMB seem to be more reliable than WebDav or FTP or KDEConnect,
etc., for Wi-Fi "network connections" between Android & Windows?

I can get them all to work once, or twice, but to keep them alive and
connected is where Windows has to be rebooted sometimes, as it won't let go
or it lets go but won't reconnect - all inexplicably to me.

Yet the SMB connections I've tested over the past week seem very reliable.
o Why?

As most on this newsgroup are aware, I've every suggested viable free
solution for seamless cross-platform bidirectional file transfer between
Windows/Linux and iOS/Android so as to keep our private data off the cloud,
where this question is _only_ about Windows:Android connection reliability.

Just a sample of some of the methods I've tested, for example, a
1. *CIFS* (eg Folder Tag, Network Browser, ES File Explorer, etc.)
2. *SMB* (eg AndSMB, Astro, Total Commander, MiXplorer, etc.)
3. *FTP* (eg PrimitiveFTP, FTPUse, FTP Server, WinSCP, FileZilla, etc.)
4. *HTTP* (eg Wifi Explorer, WiFi File Transfer, etc.)
5. *Sync* (eg MyPhoneExplorer, AirDroid, Psencik LocalSync, etc.)
6. *MTP* (e.g., libMTP, MTP, Android Studio adb, etc.)
7. *Proprietary* (e.g., KDEConnect, ResilioSync, SyncMe Wireless, etc.)

Of all these methods, the most reliable, seems to be, the SMB method.
o Why would that be the case?

As an example of the problem set, I can start a WebDav server on Android
and then connect from Windows to the Android device by a variety of methods
(some seemingly less reliable than others, by the way), one of which is:
net use Z: \\192.168.1.2:8080\DavWWWRoot /user:admin passwd /persistent:YES

Which works fine, for a while...
o But later, maybe a day or three later, it fails with cryptic error 53's.

Same story with KDEConnect, where it works the first time after a reboot,
but not always thereafter.

Same with FTPUse.
o Yet, the SMB method seems to be reliable day after day after day.

The reason this matters is that the SMB method is limited that you have to
do all the copying using the Android GUI while most of the other methods
allow you to use the Windows native file explorer for bidirectional copies.

NOTE: I've seen in some Android apps the suggestion to change Size to 3:
o HKLM\SYSTEM\CurrentControlSet\Services\LanmanServe r\Parameters\Size=3
e.g., https://play.google.com/store/apps/details?id=com.bv.wifisync
"Windows sometimes is not fast enough to reclaim resources.
Changing registry seems to help
--
One potentially complicating factor is that I use the desktop Ethernet port
to connect by Cat5/6 to a Microtik radio transceiver using its high-gain
antenna to connect to an access point quite some distance away, which is
why I need to ask some of you if you have the same issues I have but on
your presumably more conventional setups.
Ads