Actually I've been researching this subject also. I'm using T-Mobile (Boston, MA, USA) but I've determined I'm behind a symmetric NAT. I am able to establish bi-directional UDP communications with services running on public IP addresses but due to the behaviors of symmetric NAT, UDP Hole Punching is impossible for communication with another NAT'ed endpoint.
Ernest Woo Woo Games http://www.woogames.com On Mar 6, 2:14 am, gjs <[email protected]> wrote: > Hi, > > As a test, try downloading the Android Scripting Environment to your > droid, then try the SimpleHTTPServer example using the python > interpreter, it starts a http server using tcpip and listens on port > 8000, works fine for me on 3G (with Nexus One), ie I can connect to > phone from PC & browse the phone files when phone is using 3G &/or > wifi. (And no I am not using Verizon or Sprint or ATT or T-Mobile.) > > Seehttp://code.google.com/p/android-scripting/wiki/Tutorials > > The python code for this is in the tutorial under 'How to get your own > IP address' > -http://www.beresourceful.net/~rusty/blog/2009/09/gleaning-your-ip-add... > within which you can download the python scripts using the QR code > support from within the ASE. > > But yes, I agree with the other comments, it all depends on the > carriers and what they filter & block. Using an external server is > typical solution. > > Regards > > On Mar 6, 4:02 pm, "SoftwareForMe.com SoftwareForMe.com" > > <[email protected]> wrote: > > Hello, > > > For all of the reasons described, it may not be possible, using TCP. > > > It may be possible using UDP, however. > > > I have been successful at creating a bidirectional conversation between a > > [Verizon] Droid and a PC using UDP, while the same code failed miserably on > > T-Mobile. Conclusion: T-Mobile filters out the packets, Verizon allows them. > > > The only question then is how they might handle hairpin routing, and of > > course this depends on where the NAT is located. I will test this as soon as > > I get my hands on another Droid. > > > So, the scenario that *may* work would require that you: > > 1) Have some external server to help negotiate the conversation > > 2) Use UDP rather than TCP > > > Scott > > SoftwareForMe.com > > > On Thu, Mar 4, 2010 at 10:04 PM, Bob Kerns <[email protected]> wrote: > > > It's more than that. There's no reason for there to be any routes for > > > anything except phone to APN, and no reason for them to not filter out > > > all incoming requests and inter-phone traffic as a security measure. > > > > You can't persuade your cable modem to let you talk directly to your > > > neighbor, either. > > > > Even if you found cases that worked, with phones hopping from tower to > > > tower, and there being no reason for it to work as a matter of policy, > > > I don't think it's anything you could ever make robust and reliable. > > > > On Mar 4, 5:26 pm, Mark Murphy <[email protected]> wrote: > > > > Jon Dixon wrote: > > > > > Thanks for your response. Before I abandon this design, please > > > > > comment on this use case. Let's say I have two phones on the same > > > > > carrier (Verizon). Would not these phones be on the same side of the > > > > > NAT firewall? > > > > > Not necessarily. The NAT could be applied at the tower, the central > > > > office, or any number of other points that would be in between the two > > > > users. > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > > >http://twitter.com/commonsguy > > > > > Android 2.0 Programming Books:http://commonsware.com/books > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%2Bunsubs > > > [email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
