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.)
See http://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-address/ 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
