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.

Chronic nym-shifting psychopath troll...

--
Arlen Holder wrote:

Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.mixmin.net!.POSTED!not-for-mail
From: Arlen Holder
Newsgroups: alt.comp.os.windows-10,microsoft.public.windowsxp.general,comp.mobile. android
Subject: Why would SMB seem to be more reliable than WebDav or FTP or KDEConnect, etc., for Wi-Fi "network connections" between Android & Windows?
Date: Thu, 30 Apr 2020 13:48:10 -0800
Organization: Mixmin
Message-ID:
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 30 Apr 2020 21:48:10 -0000 (UTC)
Injection-Info: news.mixmin.net; posting-host="f26c789efbf3e57e688807aee0dd884ed51f0684"; logging-data="2915"; "
User-Agent: NewsTap/4.0.1 (iPad)
Xref: reader01.eternal-september.org alt.comp.os.windows-10:117176 microsoft.public.windowsxp.general:145456 comp.mobile.android:69223

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.

UPDATE:

I narrowed down the Wi-Fi LAN reliability problem to a NETBIOS hiccup...
o Basically, everything works well after a router reboot.

What seems to possibly be happening is that NETBIOS broadcasts are
apparently blocked, by default, in my Mikrotik transceiver, which, over
time, causes some kind of "hiccup" on my WiFi LAN that blocks SMB
connections over time.

The result is that, after a few days, the SMB connection won't work.
(I'm not completely sure why; I just know a router reboot solves it.)

The desktop itself has no Wi-Fi, so the motherboard Ethernet port is
connected via Cat5 cable to the RJ45 port on the Mikrotik transceiver,
which itself is connected over the air to a distant Access Point.

Anyway, the good news is I've been able to get three different Android to
Windows SMBv2 clients to work rather well over this Wi-Fi LAN...

Please see step-by-step detailed reproducible instructions he
o *Tutorial: How to connect Android to Windows as a drive letter over
*a Wi-Fi LAN for free simple reliable bidirectional copy*
https://groups.google.com/forum/#!topic/comp.mobile.android/9Lu2_dPsu6o

And here...
o *Do you know of a free Android SMBv2 (or SMBv3) client?*
https://groups.google.com/forum/#!topic/comp.mobile.android/tl3Q05QGyAw

Note: There are so many
--
Usenet is so much more valuable, and pleasant, when people share solutions.