Google App Engine TCP/IP connection - google-app-engine

I would like to set up a couple TCP/IP connections in GAE using Go. As I've searched it is impossible to get a static IP from the app engine, but can't find much data on other limitations.
Is it possible to establish a TCP/IP connection in GAE, and if so, how long can it be used before it has to be re-established?

It is clearly mentioned here that you may not open a socket from within their sandboxed environment.
Now HTTP is also based on TCP/IP, and you may "fetch" content using URLs (in Python it's urllib and urllib2, don't know much about Go). But raw SOCK_STREAM connections? NO.
regards,
Yati Sagade

The situation has changed and as of July 2013 there is an experimental Socket service available for Java and Python. It is enabled only for paid accounts, you can only create outbound connections, and there are few other limitations. Also, the docs says that the API is not stable and may be subject to changes.
As of December 2013 there is the experimental Socket service available for Go as well. The conditions in the relevant doc page are similar to the ones for Java and Python.

Related

Are there any code samples for Uno platform accessing MSSQL, PostgreSQL or MYSQL?

I have tried various ways to connect to different DB engines (asynchronously), but they all failed when I deployed the code and executed it via my browser in WASM format. The code worked well for UWP tho, so I'm a bit baffled.
Although there's a sample for SQLLite in browser, it wasn't too helpful for me. Hopefully someone could give me a few pointers to continue. Thanks in advance
The support for SQLite is about running the database inside of the browser itself, but not about running it from a remote database.
If you need to have such a support, you will need to have a .NET SQL provider that supports plain HTTP/S or WebSockets, which is available for cloud-based databases.
In general though, you may want to consider a WebAssembly app as a mobile app for which it is best to access remote resources like databases through a Web API.
Note that the Chrome developers have in mind the creation of a RAW sockets API, which would enable TCP non-HTTP connections to be created.

How to create new Exchange public folders?

We tried last night to build some code which would create a new public folder in Microsoft Exchange from within a .NET Winforms application.
Googling for code took us to a bunch of code samples involving http requests and WebDAV. We experienced all kinds of painfulness involving
The underlying connection was closed: Could not establish trust
relationship for the SSL/TLS secure channel.
and
The remote server returned an error: (440) Login Timeout.
and had to call it a day.
This morning I remembered that we had some old VBA code which used the Outlook Object Model to deal with Exchange Public Folders. Dug it out, adapted it to .NET and, hey, it works. Really it's just a couple of lines.
Is there a reason to use http & WebDAV rather than OOM? Are the WebDAV examples basically for ASP.NET development? If we could have got the WebDAV code to work in our case would it have given us any extra power or flexibility (e.g. in cases where the user has restricted permissions)?
See http://www.infinitec.de/post/2008/11/26/ExchangeWebServices-WebDAV-and-untrusted-server-certificates.aspx for the SSL thingy and http://www.infinitec.de/post/2004/12/31/Access-the-Exchange-store-via-WebDAV-with-Form-Based-Authentication-turned-on-Updated.aspx for the Login-Timout.
If you use the OOM, you rely on Outlook being installed and property configured (which can be somewhat difficult you have multiple profiles).
WebDAV ist a HTTP protocol, meaning that you have very little prerequisites. That being said, WebDAV for Exchange is a rather cumbersome protocol. There are, however .NET wrappers available (I can send you one which is free - just ping me through my website) which makes it easier.
But know that WebDAV for Exchange is only supported in Exchange 2003 and 2007. Since Exchange 2007, WebServices are available and there is even a managed API:
EWS Managed API - Download: http://www.microsoft.com/download/en/details.aspx?id=13480
EWS Managed API - SDK: http://msdn.microsoft.com/en-us/library/dd633710(v=exchg.80).aspx

Apache with Comet Support

I'd like to build a multiplayer web game application in which it supports chat. I presume the application will have to handle hundreds of simultaneous connections.
I'm planning to host my application in a shared web hosting, which has these limitations (most likely similar to PHP + Comet (long-polling) scaling / hosts):
It does not seem I can change the web server. Most likely it's using Apache.
Supports MySQL 5, PHP 5.3.x, Perl, Python, Ruby on Rails, CGI
(To be more precise, I'll be using HawkHost's shared web hosting.)
And here are my result of research, followed by my questions:
Some resources (like Python Comet Server) say that PHP is not good for handling concurrent connections, while Python is better choice. Is this true?
I've tried the long polling technique in PHP (although I don't know whether it's correctly implemented or not, like Comet issue with abandoned open connections) using "Loop endlessly until the data changes." method. This almost works. The remaining problem is that the server process never dies when the browser is closed (the server does not know that the connection has been terminated, and the data never changes). Is there any way the PHP can detect whether the browser has been terminated so that it stops the loop?
I've been looking everywhere to look for answers but still I can't conclude anything. This topic has also been asked on StackOverflow so many times, I'm sorry if I may sound repeating >.<.
Currently I am able to code using PHP, MySQL, and JQuery for JS. I'm still new to the term Comet and Server Push. If necessary, I'm also willing to learn new scripting language like Python.
I appreciate any insights of what scripting language, framework, and techniques to use to start my project.
When you have a shared hosting environment and there are a number of restrictions enforced then it's a good idea to outsource the realtime functionality. I would say this since I work for one such company, Pusher. But I hope others will back me up on this.
When using a hosted solution you can push a notification by making a HTTP request to a RESTful API. The service will then deliver the message to the connected Web Client (browser). The browser does need to include a script tag or use a library that also connects to the hosted service.
The main benefits are:
No installation or maintenance
No need to handle persistent connections - no resource usage
Really simple usage: Script tag in app and call REST API
The hosted solution handles scaling
Also, here's a list of hosted realtime solutions.
So you can use Python. Then you can use Tornado. (psst... facebook uses it)
And I had same problem with open connections. Just don't spend time for search solution in PHP - later you will be sorry. I was. Just use what is made for Comet. If you more prefere JAVA, then there is: CometD.
And for game get a normal hosting. They cheap this days.

How can I run a WebSocket server on top of GAE?

How can I run a WebSocket server on top of Google App Engine? Is it possible? Will it be possible?
Is it possible?
No.
You can't right now because GAE doesn't allow generic inbound socket connections. Each request is also limited to 30 seconds but this could easily be worked around with automatic reconnection and session tracking.
Will it be possible?
Probably.
Google has been one of the biggest (main) promoters of the WebSockets standard. I would be surprised if they don't push support for it into GAE at some point in the future. Note that the WebSockets draft standard is still in flux so Google might be hesitant to add support before the standard is more solid.
Here is the bug for WebSockets support on GAE: http://code.google.com/p/googleappengine/issues/detail?id=2535
Note that a google employee indicates it's not on the roadmap but that they know it would be useful. That's about as positive an answer as you get from google about features that have not been announced. I recommend adding your voice to that bug in favor of WebSocket support. It can't hurt.
Also, depending on your application, you may consider the Channel API which will likely have GAE support soon:
http://googleappengine.blogspot.com/2010/05/app-engine-at-google-io-2010.html
http://bitshaq.com/2010/09/01/sneak-peak-gae-channel-api/
EDIT (2015): the Channels API is available now (it has been for a while).
All of these answers are out of date.
The Channel API has been deprecated. Google strongly recommends you use Firebase.
It is also worth noting, that Google has now released the flexible environment.
With the flexible environment, you could easily allow socket connections, or use Python 3.
It's officially supported now.
See https://cloud.google.com/appengine/docs/python/channel/
EDIT: the Channel API is supported, not WebSockets. The Channel API is built on WebSockets, but it doesn't give you direct access to the WebSocket. I suppose it's good enough for typical Web apps.
As of January 9, 2019 it is officially in Beta now - but only for App Engine flexible. For example, see the Python documentation. According to the issue tracker, it will work with any language, though.
You can't.
GAE limits HTTP requests to 30 seconds, WebSockets expect to have connection open for a long time.
Will it be possible? Only Google knows this.
A couple people have gotten websockets working with GAE with the help of another server... checkout http://code.google.com/p/typhoonae/wiki/WebSockets
There's also this: https://cloud.google.com/appengine/docs/go/sockets/
It's experimental and very low level though.
Google App Engine has recently launched support for Websockets on App Engine Flexible Environment. You can take a look at their blog post.
https://cloud.google.com/blog/products/application-development/introducing-websockets-support-for-app-engine-flexible-environment
June 2019
Websocket support for GAE is now supported under SLA for Flex.
Hi everyone, I'm happy to announce that Websockets support
for Flex is now Generally Available! We've made no changes since Beta
but Websockets traffic is now subject to our SLA.
We've also published documentation for this feature for all App Engine Flex languages.
See https://issuetracker.google.com/issues/35886348#comment285
Hope helps, but seems to be supported now. 2021
[https://cloud.google.com/appengine/docs/flexible/java/using-websockets-and-session-affinity][1]

Can Google App Engine ever support SSL with custom domains (i.e. with Google Apps)? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Does Google App Engine support SSL for apps hosted as mydomain.com?
I know that GAE does not support this yet, but is there any reason it can't be done? If they can add support, I'd assume they're working on that. Have they said anything about this publicly?
There are a few different ways they might choose to handle this, including automatic IP address re-routing and SNI. It has been one of the most requested features for well over a year, and very recently, they officially put it on their Product Roadmap. It was also mentioned in their App Engine for Business announcement.
SSL for custom domains is supported for tests since October 2011.
Update:
Full description of SSL for a Custom Domain.
App Engine has now launched SSL for Custom Domains. You can choose from either SNI or VIP based SSL. Wildcard and multi domain certificates are supported which allow you to use your certificates across multiple applications and domains.
They can - there is no technical reason why not, especially with newer TLS versions (RFC 4366) which support virtual hosted SSL/TLS. Before this point an SSL session required a dedicated IP per certificate.
There is no such support at the moment but it's noted in the roadmap for upcoming releases.
You can run SSL on your custom domain by using a third-party service. Here's a HOWTO I wrote up explaining how to do it using CloudFlare:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
They found an interesting way around the one-cert-per-IP address. Since they register the certificates, they register each cert with 20+ domains on it. That way they multiplex 20 different domains on a single IP address.
At any rate, we use it at Voost and we're pretty happy with it.

Resources