Android Question Lost wifi connections and reconnecting again automatically

mbatgr

Active Member
Licensed User
Longtime User
Good morning to all. I have an serious issue with broken wifi connections and reconnecting client (B4A app) again with the server to continue the smooth operation of the app (using socket library). Is it possible for someone colleague to share a bit of another useful code here? I think that given the limitations of socket.library this is an important general issue that most members of this group would like to manage efficiently.
 
Last edited:

mbatgr

Active Member
Licensed User
Longtime User
limitations about having no tcpSocket_ConnectionLost and such things. I read something about using the phone.library to check if connection state is changed.

The server is implementing in VB6 using winsck32.

Yes, it should maintain always connected as long as the user (client) complete a particular session. So when the connection lost the app is freezing and it should reconnect to that particular user. I'm stucking in "reconnect to that particular user" portion of the code.
 
Last edited:
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
The problem is that is difficult to test the code as it needs an unexpected termination...
Anyway, does it need to use the Phone.library to check the connection status?
Because I do not have such a knowledge about networking, in order the client to reestablished connection, does it need to store somewhere on the server app the requestID, RemoteHostIP of that client etc of the connection before connection get lost?
 
Last edited:
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
Hi Erel,

I do some research on WWW and found the solution with timers and in regard to VB6, using the winsocket. PeekData method.
Is there any equivalent in AsyncStreams object in B4A?
thank you in advance
mike
 
Upvote 0

Troberg

Well-Known Member
Licensed User
Longtime User
The server is implementing in VB6 using winsck32.

I'll advice against winsck32 in VB6, it has some really problematic bugs. I've used it in several projects (for example a web server), and it has severe problems.

Even when using TCP, it sometimes drops packages. No reason, they are just dropped and you get no information about it. I've traced the problem, and I can see that I send the package, and I can see that on the other end (which may be on the same machine), nothing happens (occasionally).

So, even if you use TCP, you'll have to create a protocol where an acknowledge message is sent after receiving data, and if the sender don't get the ACK within a certain time frame, it resneds the data. Furthermore, you need to ID your packages, so that, if the ACK gets lost, the recipient knows that the re-sent package is a duplicate and needs to be ignored.

It's not really predictable, other than that it seems to be more common the more sockets you have open.

Really messy, and it's a known bug which MS has known about for a long, long time, but won't fix. Damn you, Bill Gates, damn you!
 
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
Thank you Troberg for your reply.
I use it for wifi server-client app with the packets been no more than 200-300 bytes each time, and until now with 2 users i have tested it no such problems occurred.
I expect to use it with no more than 5-7 users max, so do you think that such a problem can happen? In this case, do you have a suggestion using another third-party activeX control for VB6 and VB.NET respectively?

In any way, supposing that i go with it and in regard with my question, is there any way to auto-reconnect the B4A-client with the VB6 server winsck32 app ? ANy equivalent with PeekData method?
 
Upvote 0

Troberg

Well-Known Member
Licensed User
Longtime User
I ran it with only short commands, and lost as much as 2% of the commands. My solution is as I said, to have a protocol that doublechecks everything.
 
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
I ran it with only short commands, and lost as much as 2% of the commands. My solution is as I said, to have a protocol that doublechecks everything.
So, as I understand you think that the problem I confront is related to this winsck bug.
Well, in that case is it possible to share your code protocol with me....? I would appreciate any help.
 
Upvote 0

Troberg

Well-Known Member
Licensed User
Longtime User
I don't know if it's related to the WinSck bug, but it's so unpredictable and nasty that it makes me advice against using it.

As for the protocol, it's so woven into the other code that I can't extricate it with a reasonable amount of work. The principle is simple, though:

Sender: Send a package, prefixed with a package ID.
Reciever: Get the package. Return an acknowledge package with the id, basically "I got packet number 1234". If sender has already got package 1234, then do nothing more with it, else do whatever needs to be done.
Sender: If it doesn't get the ACK package within a certain time, resend package (which takes us back to the start). Ignore duplicate ACK packages with the same ID. If it gets the ACK, send next package.

Of course, the roles may be reversed if it's a two-way connection.

The sick thing about this is that this is exactly what TCP should take care of, so we won't need to. This is, more or less, what TCP does, but somehow, WinSck has messed that up.
 
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
Yes, you are right, this is the thing that exactly TCP should take care of, and the sick thing is that it happens un-expectantly to only 2% of the cases...
It is quite a straight solution. However, if this is the case I prefer to use another third-party control, more reliable and with more features. Do you have any alternative to winsck to suggest especially one that can be used with VB.NET/Windows 8.1 and having in mind that the client would be always a B4A/B4I app?
I think that maybe Erel would have something to suggest about...
 
Last edited:
Upvote 0

Troberg

Well-Known Member
Licensed User
Longtime User
I tried to find alternatives, but couldn't (at the time) find any. It's over five years ago, though, so things may have changed (although, not much has happened in the VB6 world in the last five years...). Also, this problem is in VB6, I don't know if the same problem exist in VB.Net, though VB.Net have some other issues which may be problematic if you need to maintain a large number of connections (it is more or less based on the assumption that each connection runs on it's own thread, and if you want thousands of connections, this is bad).

Google VB6 winsock problems and you'll find lots of info on the problem. MS has confirmed the issue but won't fix it.

If you find a solution, please post it. It would solve a lot of issues for me.
 
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
thank you Troberg,
I have found something, seems interesting, iIf you have your e-mail I will send you some links to have a look and get your experienced opinion... I turn to private conversation
 
Last edited:
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
Try B4J. It is the easiest way to communicate with B4i and B4A applications.
Thanks Erel, but is difficult or maybe too late at the moment to jump to B4J. How about the convertion time of my little simple app to B4J and what advantages it would be offer in regard to the winsck32 problem? I afraid the possibility to get stuck to things I never work before otherwise I could try...
 
Last edited:
Upvote 0

Troberg

Well-Known Member
Licensed User
Longtime User
thank you Troberg,
I have found something, seems interesting, iIf you have your e-mail I will send you some links to have a look and get your experienced opinion... I turn to private conversation

(edited mail address out as it wasn't needed anymore)
 
Last edited:
Upvote 0

mbatgr

Active Member
Licensed User
Longtime User
Hi Erel, trying to solve the wi-fi little problem., do you thing that it would be better if i use the AsyncStreajmsText instead of AsyncStream may solve the problem. I use only text messages and on VB6 server and B4a client messages I use the chr$(4) as an end of line character sent to each other.
 
Upvote 0
Top