smartfoxserver.com

Hi there,

My problem sounds similar to this one: When i am connecting directly, everything is fine. When i connect through the bluebox, at some points my client stops reveiving messages.

Sending still works. Other people receive my chatmessages and Variable-updates, but i don't even receive my own public messages.

I could not yet pinpoint the exact moment when this happens. There seems to be no special message perceeding the blackout. The Message Queue ( http://IP/BlueBox/HttpBox.do?debugCmd=main ) starts to fill up, and eventually my client is disconnected.

Here's what the debugCmd says:


This time, it happened approximately 18 seconds after my connection, so i doubt it can be a timeout already. The que is already filling up. This one would have been another user joining the room.

Jetty Runs on 80, SFS runs on 9600. I found references to the client_request_idle_time so i added it to my config like this:


SFS is 1.6.5, Bluebox is 1.0.5 (both updated from clean installed 1.6.2 SFS Pro)

My greatest problem here is: How do i debug this. I tried Wireshark, but i can't find anything out of the ordinary.

Any help will be greatly appreciated.

Is it possibile to try the application? If so I'd like to see the problem in action.
PM me the url if it's available.

Thanks

Hi Lapo,

I have investigated this issue further, and i am now pretty sure, that it's not related to the server configuration, but to the client.

What happens ist this: When we are sending many messages at once (sendObject, to be specific), something happens, so the SmartfoxClient does no longer do the HTTP-Polls.

I am sometimes able to get it back working by calling SmartfoxClient.handleDelayedPoll(). (which i made public for testing purposes, this was only done for testing, i am aware that this is not the way it is intended to be used).

My guess at the moment is, that there's some kind of hiccup with the setTimeout() in SmartfoxClient.handleHttpData() when there are large numbers of requests at once.

We are now reducing the number of concurrent requests from this function, and hope this will be a good workaround for this issue.

On another note: we have tried to reproduce this issue with sendPublicMessage with a send-delay of 50msec, but there were no problems. If you are going to test/reproduce this issue, i'd recommend going for even shorter delays and sendObject-calls.

Once again, thanks Lapo for your support!

supplemental: we were also able to reproduce this issue with rapid setting of user-vars (like setting x and y position 10-15 times with a very short delay).

Might simply depend on the size of the message? SendObject and setUserVariables usually generate larger messages than a sendPublicMessage.

What timing are you using for the httpPollSpeed setting?
Was the test performed in a local environment or over the internet?

Test was done with the off-site demo server, not local.
The pollSpeed is 500msec

The sendObject sends ~190 bytes (size of the sfsHttp=... data in the HTTP-Packet). The whole HTTP-Request has about 300 bytes. In some instances we sent ~20 of those per second. These were all received by other users (blueboxed or not), but the own client stopped polling afterwards.

I think the size (or number) of the packets should not have an effect on whether or not the next polling starts. Going over the adobe livedocs for setTimeout (http://livedocs.adobe.com/flex/3/langref/flash/utils/package.html#setTimeout), i found out that they suggest not using setTimeout, but creating a Timer-Object instead. I don't know why, but maybe this is something you want to have a look at.

The sendObject sends ~190 bytes (size of the sfsHttp=... data in the HTTP-Packet). The whole HTTP-Request has about 300 bytes. In some instances we sent ~20 of those per second.

So you suggest that the 20 messages per second could be the cause?
Have you tried lowering the frequency of messages?
What happens if you only fire, say, 5 msg/sec
Same problem?

Hmm... i am again completely helpless:
I reduced the sendObjects to once every 1500msec - and i still get this issue. I will have to try something else.

Ok, it would be great to see this in action in a local network in order to rule out network problems.
Anywyas, let's suppose that it's not the message frequency (which in fact I didn't expect) and let's assume the problem could be in the message, could you send me the details of what data is being send with the sendObject?

Thanks

Would a recording from wireshark be useful?

Sure, but also a simple transcript of the Flash debug window would help too.
If you can send both, it would be great.

It looks like there're only a couple of possibilities:
1- you are sending some data that breaks the communication. It's unlikely but let's check it anyways
2- there's a network problem.

Sorry if I insist but I think you should run the same application in a local network and see how it behaves. This would quickly tell us if it's an application issue or a network issue.

I have been able to test in a local network scenario, but i can reproduce the error here as well.

I will be sending the traces in a couple of minutes via PM.

Use email instead, if you don't mind.

Support > Contact Us
from the main menu

and the solutions was... ??

I have the same problem, clients are able to send and receive data ....but after random time clients stop receiving data from server but are able to send.

Was there any solution in this topic?