Concern about using BB

Submit all your BlueBox related questions or report a bug here!

Moderators: Lapo, Bax

soywiz
Posts: 5
Joined: 28 Mar 2011, 11:28

Concern about using BB

Postby soywiz » 28 Mar 2011, 11:39

I was considering using SFS 1.x and BB, but I watched the AS3 sourcecode for BB and noticed that every time a message is sent, it generates a new HTTP request. I need all packets to be sended in order, it is true for SFS because it uses a TCP connection, but what about BB? What if there is variable lag and a packet I sended before arrives after? Is BlueBox servlet reordering packets internally? If not, I should reorder all the packets in my own code? It could produce lots of hard-to-track problems in the future if not.

Thanks in advance and regards.
User avatar
Bax
Site Admin
Posts: 4609
Joined: 29 Mar 2005, 09:50
Location: Italy
Contact:

Postby Bax » 29 Mar 2011, 06:24

The HTTP protocol is TCP based.
Paolo Bax
The SmartFoxServer Team
soywiz
Posts: 5
Joined: 28 Mar 2011, 11:28

Postby soywiz » 29 Mar 2011, 08:38

OK. Maybe HTTP protocol is TCP based, but you cannot assure that every requests runs on the same connection. Indeed the HTTP requests are usually handled by the browser and not always are Keep-Alive. And you don't even know if the next http connection of the current user would be handled by the same jetty acceptor. And I think I can reproduce the misbehaviour it with variable lag or even with two acceptors and a semi-long-time response.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 29 Mar 2011, 09:29

This problem exist for sockets too.
The question is why would you send two concurrent requests from the same client?
99.9% of the cases you send one request, wait for the asynchronous response event and so on and so forth.

Even in a realtime scenario you don't send updates simultaneously. You usually wait some 50-150ms between requests. In this case it is possible an out-of-order scenario but this is just normal in multiplayer development and your code must be able to handle that.
Take into account that the best approach for fast updates is using UDP which is completely unreliable.
Lapo
--
gotoAndPlay()
...addicted to flash games
soywiz
Posts: 5
Joined: 28 Mar 2011, 11:28

Postby soywiz » 29 Mar 2011, 09:43

Not in a TCP connection.
You don't even need to send a packet concurrenly but had a temporal connection problem or a big lag. This is common on connections that are made from one continent to another for example if I decide to create a server on Europe and have people connecting from America or Asia.
Even if you wait 50ms or 150ms in some cases you would have problems.
I didn't want to use SFS for realtime.
I wanted to include a hash parameter depending on an unknown algorithm and depending on previous messages to avoid cheating, having in mind that SFS is using a TCP connection and packets would arrive in the same order. I cannot use BB on that scenario then. I can only rely on the most restrictive product I use.
BB could aggregate some packets and send several of them after having a bunch of them or have wait enough time without new packets queued instead of creating a new http request for each message. Or at least reordering packets on the server simulating a TCP connection.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 29 Mar 2011, 09:50

Not in a TCP connection, what?
I don't follow you.

You don't even need to send a packet concurrenly but had a temporal connection problem or a big lag

If I send packet A and packet B over a TCP connection I will always get packet A and then packet B on the other side. Regardless of the lag.
Lapo

--

gotoAndPlay()

...addicted to flash games
soywiz
Posts: 5
Joined: 28 Mar 2011, 11:28

Postby soywiz » 29 Mar 2011, 09:57

I mean that the problem of getting packets disordered don't happen over a TCP connection.

If I send packet A and packet B over a TCP connection I will always get packet A and then packet B on the other side. Regardless of the lag.


Right. We are talking about BB and using HTTP.
You are creating a request for every message sent to the server.
You can create a HTTP request (using a TCP connection) and then create another HTTP request (using another TCP connection). And it is possible that the second connection reaches the server before the first one. And BB sends the packets to SF in a wrong order.
That was what I meant.

Image

Note that if we have a constant lag, packets would get in order, but with a variable lag it could get disordered. Some connections uses a different route sometimes, and also TCP could drop some packets and have to retry to send some chunks and allow the other HTTP connection to be handled before.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 29 Mar 2011, 10:55

Yes, this is possible.
However the possibility is so low that it becomes negligible. And in 4 years of using the BlueBox no one has ever brought up this issue.
If the client has such a bad connection that jumps from 100ms of lag to 1000 every millisecond it will probably experience some issues, but it's not even said. It depends on how the client uses or re-uses connections. HTTP clients tend to reuse connections.
So I think we're splitting hair here :)
Lapo

--

gotoAndPlay()

...addicted to flash games
soywiz
Posts: 5
Joined: 28 Mar 2011, 11:28

Postby soywiz » 29 Mar 2011, 11:17

Maybe nobody noticed that some kind of problems were caused because of that.
Anyway, maybe it's unlikely as you say and I won't have those problems in production.
I will continue evaluating SF to see if it fits to me.

Thanks for the replies, and regards! :)

Return to “BlueBox”

Who is online

Users browsing this forum: No registered users and 13 guests