I've been seeing the same behavior myself.
Can someone address this please?
Thanks
Guy
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group,
> Is it the delay in discovering the disconnect that's the issue?
Exactly...
The connection stays open to accept data from the server. There are
definitely points in time when this wouldn't happen for a few minutes, and
if the connection dropped, that wouldn't be a problem if the client noticed
Well, I don't grok NAT enough to conclude that it's wrong. But I don't
see why they'd do it -- unless they're trying to minimize traffic.
Seems kinda trivial -- and likely more than offset by the later
attempted transmit.
I'm not sure what problem you're trying to solve. It can certainly
happen th
Hey Bob,
Thanks a lot for the response :)
After a few more hours tonight working on the problem, I've got a bit more
information to present.
>From everything I'm seeing, it looks like the issue has to do with NAT'ing
at the network level (tmobile I'd imagine). The connection is definitely
NAT'd
This is expected behavior. TCP connections time out if the connection
is lost, or either side dies. That way, you don't have systems
drowning in dead connections.
The RST packet is telling you that the server has forgotten about the
connection. The client may even report it directly, if it realize
5 matches
Mail list logo
