Forums

Websockets, Flask and PythonAnyware server

Hello! I am following this tutorial (http://dev.hasenj.org/post/38188152502/adding-web-sockets-to-flask-apps) to add websockets to a Flask application. In the tutorial they switch the built-in flask server to a gevent server using gevent-socketio:

@werkzeug.serving.run_with_reloader    
def run_dev_server():    
    app.debug = True    
    port = 6020    
    SocketIOServer(('', port), app, resource="socket.io").serve_forever()

if __name__ == "__main__":    
    run_dev_server()

Does anybody know how could that work with the PythonAnyware server? If I try to run my own server like in the example I get a Permission denied error.

[edited by admin: formatting]

Unfortunately right now we only support WSGI-based apps on PythonAnywhere, which means that that won't work, and additionally that WebSockets won't work. That's something we're going to fix, and I've added an upvote on your behalf.

Ok, thanks for the fast response!

No problem, sorry it couldn't be a more promising one!

Hello. Keeping topic alive, if I could trouble you for a status update.

Is it still the case that there is no way to run a socket server on pythonanywhere ?

eg: .js client connecting to .py socket using system such as http://autobahn.ws/

It is still the case and we're not planning on changing it any time soon.

thanks for the update.

Hi, understand that pythonanywhere is unlikely to have support for WebSockets anytime soon (judging from the discussion above) is there any other way that I can implement an instant messaging system within my app in pythonanywhere?

Hmm. One possibility would be to use some kind of long-poll HTTP. You would make ajax requests and your server would stream out responses. The problem with this approach is that each running connection would tie up a complete web worker thread, so that would become expensive quite rapidly if you had a non-trivial number of users.

Perhaps a better alternative would be Ajax polling? You'd have a "get messages on thread" view which would take a "messages since this ID" kind of parameter. Then your page would make an Ajax request to the view with that parameter unset to get all messages to date when it connected, and would then poll every minute or perhaps somewhat more frequently to get messages since the last one it had seen.

Could there be a client-side/javascript solution involving webrtc, or one of the "realtime" framework thingies?

Nice idea, that would be nifty!

Hi Harry and Giles, Thanks for the Ajax polling and webrtc suggestions, most appreciated. I'll see what I can put together.

So just checking on this feature. I was wondering if this will be implemented in the future. It is 2015 now :)

...and we don't even have flying cars :-(

More seriously, it's definitely on the list. There are just quite a number of other things that are higher-priority right now.

thanks, I will wait for it :)

It's still in our list of things to do, but it's a very long list, so we can't make any promises.

+1 for WebSockets (with Tornado in my case)

Cheers, Tom

Cool. I've upvoted the ticket for you.

Hello Administrators,

I also recommend that you provide socket support. Please upvote it on my behalf too.

Hi! +1 for WebSockets (Tornado server is needed for me :))

Hi!

I have just found this topic and I also think that it would be nice to have this implemented. :)

Cool. Ticket upvoted.

sockets @ pythonanywhere that would rock.

Thanks! Another upvote added to the ticket.

I would like to see WebSocket support if possible. Can you add another vote?

Thanks!

Sure. It's added.

Lack of websocket support was the reason why I had to migrate my project. I hope to return soon!

websocket support much needed. upvote one for me.

Upvoted!

Upvoted!

Is the list of feature requests publically visible somewhere? I'd like to see websockets implemented too, but I'm interested in the context of what I'm implicitly down-voting as a result.

If the brexit vote teaches us anything it is to understand when you for something is usually at the cost of something else :)

Heh, you're quite right about that!

We don't have a public list -- we've noticed that when companies do that, there's a lot of pressure to work specifically on the things at the top of the list, which isn't necessarily the most important thing from a systems perspective, or the right order to do things.

This is because there are also non-obvious connections between things; for example, in order to get WebSockets working sensibly, it would make sense for us to sort out what we call "long-running tasks" first -- that is, come up with a system where people could start Python processes that would run forever, or rather, be restarted if and when they crashed. That's the best way we can see to supporting WebSocket servers like Tornado. But it's also a really useful thing in itself, and it's something that people are asking for independently. Now we can add to that the fact that for obscure internal architectural reasons, getting long-running tasks working is best achieved by starting with some changes that will allow us to provide different system images for different users, so that new users get (for example) Django 1.10 for all versions of Python, while existing users keep the old versions so that their code doesn't break.

If we had a public list, it might have WebSockets at the top, then a bunch of other stuff, then long-running tasks, then right down the bottom might be the different system images for different users. So when we said "we're working on the different system images" thing then we'd look like we were ignoring what everyone wanted, and people would get upset. If this were a one-off then we could probably explain it and everyone would be happy, but if it kept happening (which is likely) then it would mean we'd spend a lot of time explaining and less time coding the stuff people want :-)

However, all that said (and apologies for the lengthy post!), and to answer your main question... there are some broad categories of things that can be treated as competitors for WebSockets. A few things that come to mind:

  • Education and collaboration features
  • Hosted MongoDB, REDIS, and memcached
  • Better support for mobile devices/tablets

Hi.. Can i get a refund? Payment options deceived me that i could host a chatbot framework but the very basic websocket/socket io is not working. I was on heroku. Even if you could count the number of search results of chat applications on google, you would enable sockets.

Sure! Just downgrade to a free account on the "Account" page and then send us an email at support@pythonanywhere.com regarding the refund.

Just to make sure -- you're talking about not being able to create a WebSocket server, right? WebSocket clients should work fine from PythonAnywhere. WebSocket servers are on their way, there's just quite a lot of work we need to do to enable them.

Glad to hear you guys are working on Websocket servers.

Upvoted!

also btw- there are third party platform-as-a-service offerings such as pusher that you can use in conjunction with pythonanywhere to get websocket functionality

Thanks for the upvotes! Noted.

Just as a little background -- delivering this requires three steps on our side:

  • Providing an ability to keep a process running constantly, restarting it if it crashes ("always-on tasks"). The first version of this won't support any kind of server, it will just be useful for people who want other non-server programs to keep running constantly -- Twitter scrapers, that kind of thing. Doing it without the network stuff allows us to deliver something that a certain number of people have asked for, and to sort out any bugs in the persistence side of things, without having to do a "big bang" release that supports lots of different things.
  • Internal network support for always-on tasks. That would extend the first release and allow you to run an always-on task that could operate as a server inside the PythonAnywhere cluster. This is also useful on its own, and should allow things like Celery servers, which a lot of people have asked for. External network routing is hard, so not doing it in the first cut again allows us to deliver something useful and sort out any bugs before moving on to...
  • Finally, external network routing for always-on tasks. This is an extension to the previous step, and would allow WebSocket servers

How far are you guys at implementing Websockets to Pythonanywhere?

No progress to report I'm afraid.

Hello, is there any updates on this? I am also in need of websocket access and would rather not use a polling AJAX system (this would eat up a lot more resources/bandwidth than websockets) I am not sure if this is of any help, but I was able to get uwsgi websockets working on my own ubuntu computer by simply installing libssl-dev and then running pip install uwsgi. Please let me know if this is something that can be done. I noticed many other people also would like to see this feature on pythonanywhere.com

P.s nginx now supports websockets

There are no updates at the moment.

Drat. I launched my account here specifically to host a websocket back-end to collaborate with a front-end developer.

FWIW, I'm using Flask-Sockets for the websockets support.

It'd be awesome if the service supported long-running processes that happened to sleep a lot. I.e., meter on actual CPU runtime, not process wall clock time.

:-(

Yes, we're definitely going to support long-running processes reasonably soon. Our system update tomorrow, at least in part, is making some infrastructural changes that will make it possible for us to do that. The first version probably won't be externally routable (so, you'd be able to run something like a Twitter bot that made outbound connections and stayed running all the time, but you'd not be able to run a server). But the aim is to support async servers like aiohttp as soon as we can after that.

I should say, BTW, that we meter CPU usage by busy time rather than by wall clock time in general; the only exception to that is on the total runtime of scheduled tasks.

Any update on websockets? I'm supposed to be teaching a class at my old school for a university module and wanted to teach them about websockets and web communications.

I guess it could be possible to replace most of the websocket functionality with a restful api but you can't send and store binary data that way such as needed to store photo; plus it be far slower as my aim was to teach the students how to implement a realtime game such as bomberman.

No updates on websockets.

Any updates yet? This would be amazing if I can finally get my app to work :)

Not for websockets. Sorry!

5 years from OP and still no websocket ? Do you know if websocket is coming anytime soon ? Thanks.

No, we're probably not going to have web sockets any time soon.

hey glenn

can haz websockets yet pls? :-(

pretty pls

with cherries on top

:'(

We do have a plan to support them; the first phase was always-on tasks, which we released earlier on this year. The next phase will be the ability to run internal servers (that is, ones that your code running on PythonAnywhere can connect to) inside always-on tasks, so that you can run things like redis and MongoDB. And the final phase will be to allow routing to those tasks from outside PythonAnywhere -- which will make it possible to run WebSocket servers.

The downside is that always-on tasks cost us too much to run for us to offer them in free accounts :-( Also, we don't have an official timeline for the support -- it's high on our priority list, though.

9 mos. later (or 7 years, depending on how you look at it;)). Any updates? Also, are you saying that when and if you do begin supporting flask-socketio it will only be for paid accounts?

No updates right now. When we do support it, we'll definitely announce it.

And yes, it is pretty much certain that it will only be for paid accounts. Traditional WSGI-based sites can be shut down when they are not receiving traffic, as they can be started up again when needed; that is what makes it possible for us to host them for free. SocketIO-based sites cannot, because they may have open connections to client browsers, so we would need to keep them all running 24/7, which would cost us too much money to provide them for free.

I assume there is still no support for web sockets ?

Any viable alternative from PA ? (I'm a paid account).

Not yet.

Still no support for web sockets? For paid accounts?

Not yet, but it's at the top of the priority list.