Android Question Lost wifi connections and reconnecting again automatically

[mbatgr]

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.

 

[Erel]

Which limitations?

How is the server implemented? Must you maintain an always connected connection? One of the advantages of http servers is that nothing bad happens when the connection is broken.

 

[mbatgr]

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.

 

[Erel]

You need to use AsyncStreams and handle the Terminated and Error events.

 

[mbatgr]

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?

 

[Erel]

I recommend you to go over AsyncStreams tutorial. There are also many examples in the forum.

Networking is indeed not a simple topic.

Anyway, does it need to use the Phone.library to check the connection status?

No.

 

[mbatgr]

I'm already searching it... thank you for your support

 

[mbatgr]

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

 

[Troberg]

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!

 

[mbatgr]

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?

 

[Troberg]

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.

 

[mbatgr]

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.

 

[Troberg]

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.

 

[mbatgr]

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...

 

[Troberg]

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.

 

[Erel]

Try B4J. It is the easiest way to communicate with B4i and B4A applications.

 

[mbatgr]

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

 

[mbatgr]

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...

 

[Troberg]

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)

 

[mbatgr]

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.