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.
Concern about using BB
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.
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.
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.
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.
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.
I mean that the problem of getting packets disordered don't happen over a TCP connection.
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.
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.
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.
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.
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
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
Who is online
Users browsing this forum: No registered users and 25 guests