Forums

@ger7777777: Welcome to PA!

I'm a little confused...Are you really trying to connect to 'http://www.pythonanywhere.com',80 in your code or did you change it for the purpose of demonstration?

In your server you're attempting to listen on an interface specified by a hostname which fails to resolve - this won't work. Even inthe name did resolve, it wouldn't be an address that corresponded to an interface on the virtual machine your code runs in. If you bind to the empty string it'll accept connections on any interface, which is typically what people want - this is equivalent to specifying INADDR_ANY in the C sockets API. In future, I suggest always doing this unless you have a good reason to only accept connections on a particular interface:

serversocket.bind(("", 80))

However I don't believe it's possible for PA applications to accept external connections yet, so this won't work here. The web application frameworks provided are a special case which run behind a HTTP reverse proxy which is why they work, but can only accept HTTP. They don't run in quite the same environment as your console applications.

I believe the PA boffins are considering how best to implement listening on arbitrary ports, but it's not done yet and may well only be open to paid accounts when it is.

Finally, the reason it appears to be working is that you're connecting to the PA website, which is expecting a HTTP request. Since you're not sending one, you get an appropriate HTTP error response. You're not actually connecting to your server at all.

EDIT

I just noticed that in the "creating a socket" section of the Python sockets HOWTO, it states that using INADDR_ANY will result in a socket which only listens on the local machine. I've never heard such a thing and I've often used this for sockets which listen quite adequately on all external interfaces. Does anybody know whether this is true on some platforms, or if it's just a plain error?

This specific quote is:

A couple things to notice: we used socket.gethostname() so that the socket would be visible to the outside world. If we had used s.bind(('', 80)) or s.bind(('localhost', 80)) or s.bind(('127.0.0.1', 80)) we would still have a “server” socket, but one that was only visible within the same machine.

I agree with the binds to localhost and 127.0.0.1, of course, but my understanding has always been that the empty string is an alias for INADDR_ANY for IPv4 sockets (or I gather "::" for IPv6, but never had a chance to test that yet) and I don't see why that would be restricted to the local machine.

Thanks for jumping in Cartroo and a2j. You are correct in noting that ger7777777 is connecting to our web server and getting bumped out because he's not sending a correct http request. We saw these errors appearing in our logs and wondered about them, but there wasn't enough info to narrow it down.

@ger7777777, we don't allow arbitrary socket connections to PA, mainly because we haven't worked out a way to stop users on the same machine from stepping on each others' toes. We'd like to do something to allow this, but it's not a small job and there aren't many users that need it (at least that we know of).

.

Nothing says you can't do what you want. You'd just have to write your game with a RESTful interface. I.E. program your game server to respond to http requests from your client.

@ger7777777, @a2j is right. A simple webapp would do exactly what you want and would have simpler server-side code than if you tried to write your own socket server.

.

I'd argue that the performance will be dictated much more by how you code your game way more than whether you are using sockets directly or not. First prototype your game. If once you have it working you are satisfied with performance, then you're done. If you need more performance once it's working then you refactor out some of the delays until the performance is acceptable to you and/or your users.

.

@ger7777777: Glad you're here. I hope you find this community to be just what you are looking for. I tried connecting to your site and didn't get a response, so apparently you don't have a game with a browser interface at this point. Anyway I wish you well as you work on your project!

OK! @a2j....THANKS FOR YOUR GOOD WISHES!. Thanks to all!

Just to add my 2 cents a little late (I've been away for a few days)...

The performance is likely to be better with a web app than raw sockets code, because the HTTP request is being parsed and processed by optimised library code, a good deal of which is written in C (and hence likely to be a lot faster). Certainly the chance of making mistakes during the parsing process is drastically lower.

Writing code at the sockets level isn't difficult per se, but it can be fiddly and it's quite easy to make mistakes. For cases where they're appropriate, therefore, web applications make an attractive alternative, especially as the Python WSGI specification makes it very easy to move them around between different environments.

The only thing you might find trickier with a web app, however, is if your game requires very frequent updates - more than once or twice per second, for example. In this case, a custom protocol might be more appropriate for performance reasons. These cases are fairly rare, however.

The other thing to bear in mind is that if your game does do frequent updates, make sure you use a persistent HTTP connection as opposed to reconnecting each time. This will incur significantly lower latency.

..