missing connection response

[tcarr]

Using IP address instead of domain name is ok with our own hosted flash game because we can change the code and upload the new game when our IP address changes. But for the mobile app it is not practical because we have to go through the review and approval process. Right now I am afraid when we submit our app for review it will be rejected because reviewer can't connect.

Excellent point.

The mochi reviewer actually was able to connect with our own hosted game but could not with the standalone swf file hosted on their site. I assume that means his PC has no problem accessing those ports on our server but not sure what happens when the swf file is hosted on mochi server.

Are you using a custom policy file on the ES5? I assume that mochi is already set up with appropriate policy files that allow swfs on the site to load content from other domains (which the ES5 connection would be).

If we can see on the server side there is indeed connection request from users while user can't connect, does that mean DNS is definitely not the problem? I do see a lot of netty.ChannelOpenedHandler - clientId: xxx has connected messages in the ElectroServer5.log file. Does that mean server has received the client's connection request?

If there's a logging line about a given client, then it did reach the ES5. You probably want to disable that particular logging line however.

Can you elaborate the _es.engine.close() part?

See this discussion on StackOverflow. The idea is to prevent the HTML window or AIR app from being closed until the Flash player tidies up.

Does having both BinaryTCP and HTTP in the settings mean client will try BinaryTCP first and HTTP if that fails? How long will the client wait for BinaryTCP before trying HTTP?

Yes, it will try TCP first, then HTTP. This page of the manual explains the defaults and how to customize the time the client will wait before giving up on a particular connection.

Another thread on this forum that may or may not be relevant has turned up a problem where the ES5 stops accepting new connections (at least until some existing users break their connections). Jason is looking into it; this other thread's situation is probably due to a leakage of file handles caused by users connecting then doing a dirty disconnect without logging in. For Unix servers, you can improve this by setting a high ulimit value, and a daily reboot of the ES5 if you still have problems. Hopefully this fix will be available soon.

[chengen]

Are you using a custom policy file on the ES5? I assume that mochi is already set up with appropriate policy files that allow swfs on the site to load content from other domains (which the ES5 connection would be).

We are not knowing use a custom policy file on ES5. We did enter some settings from the ES5Admin console (-Detio.synchronousWrites=false) but the enable custom policy file check box is not checked.

Another thread on this forum that may or may not be relevant has turned up a problem where the ES5 stops accepting new connections (at least until some existing users break their connections). Jason is looking into it; this other thread's situation is probably due to a leakage of file handles caused by users connecting then doing a dirty disconnect without logging in. For Unix servers, you can improve this by setting a high ulimit value, and a daily reboot of the ES5 if you still have problems. Hopefully this fix will be available soon.

Our problem seems to be the same as I originally reported it. And it seems to be somewhat related to this issue, which is supposedly fixed by 5.3.2.

[tcarr]

If you don't enable the custom policy file checkbox, then you are using the standard policy file, which should work as far as ES5 is concerned.

I'm not sure what else to suggest, other than trying the fix that Jason is working on for the file handle leak.

[chengen]

I will change nothing for now and see if I can get some help with testing on the connection issue. If the problem is widespread, I will have to try those things you suggested. Although the fixed IP can't be a final solution for us and separating HTTP and ES5 server is also kind of painful, especially just to setup for testing.

[tcarr]

If you can find a user who can't log in who is fairly technical, you can ask that user to do the telnet test (or possibly just ask the user whether his ports 9899 and 8989 are blocked). If the user can use telnet to get to the ES5 on the port, then separating HTTP and ES5 won't help, because that's not what it preventing the connection.