| Pages: 1 [2] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

xDaKewlGuyx
Pator Tech School
|
Posted - 2008.01.17 12:31:00 -
[31]
Originally by: Washell Olivaw
Originally by: xDaKewlGuyx ~bump~
You know what would have helped getting an answer?
Not insulting their work in the subject line and taking a more civil tone in reporting what you noticed.
I'm not going to compliment something that sucks. And I'm most definitely gonna bag on them for adding lots of bells and whistles before they fix some basic underlying problems that have been in since beta.
|

Jaketh Ivanes
Amarr Do Or Die And Live Or Try The Kano Organisation
|
Posted - 2008.01.17 14:37:00 -
[32]
Originally by: xDaKewlGuyx
Originally by: Washell Olivaw
Originally by: xDaKewlGuyx ~bump~
You know what would have helped getting an answer?
Not insulting their work in the subject line and taking a more civil tone in reporting what you noticed.
I'm not going to compliment something that sucks. And I'm most definitely gonna bag on them for adding lots of bells and whistles before they fix some basic underlying problems that have been in since beta.
Well, I could be an asshat and call you a lot of names and have some valid point buried among all the bile. What do you think you would hear? "You have a problem with your left tire"? or "***** you have a ******* problem with your ******* left tire, you ***********"?
Most people react and hear the insults, forgetting (well, not hearing is a more accurate description) anything constructive you might have said. Same goes with written words. First thing people reacts to and focus on, is your insulting manner. Personally, I hope CCP will completely ignore this thread on just such insulting language.
|

Gaogan
Gallente Solar Storm Sev3rance
|
Posted - 2008.01.17 16:56:00 -
[33]
Originally by: Draygo Korvan MTU determines maximum fragment size, not some TCP flag. TCP can set the MSS (maximum segment size) its willing to transmit but that won't prevent fragmentation if the MSS is bigger than the path MTU.
Any packet bigger than the path MTU (any hops MTU size between the server and the client) will be fragmented, or denied with a Destination unreachable (datagram too big).
What happens when the do not fragment bit is set is that when a packet too large is attempted to be transmitted instead of fragmenting the packet it will be dropped or 'stuck' and the sender will recieve a Destination unreachable (datagram too big).
Setting that bit is a way to try to discover the path MTU, but is generally left at 0 during regular data transfer. (And EVE generally has that set to 0, which it should be).
And a [TCP segment of a reassembled PDU] is a fragment of a packet.
I do agree with your assertion that Eve should be using UDP instead of TCP, I know that changing eve's netcode will take a lot of time as well.
Except that the packet was NOT fragmented because the IP do not fragment bit was set. So if it did exceed the MSS at any point, it would have been dropped. Also you can see that the IP fragment reassembly fields are unused.
Originally by: RaTTuS why? the infiband is just for server use it will not affect client software
udp is not guaranteed delivery - you'll get many more desyncs that way
they should try and make packets smaller - though it still works down a 56k modem so it cannot all be bad [though dont do fleet battels or jita there]
Non guaranteed delivery is the whole point: most of the data the server sends are updates to existing information. That means things it just sent are frequently obsoleted so there is no need to retransmit them if they got dropped. NOT retransmitting such obsolete data means you get less wasted bandwidth and thus, less lag.
Smaller packets are also more wasteful since the ratio of usable data to headers decreases.
Originally by: Anaalys Fluuterby
True, but UPD also does not gracefully run through firewalls as well and can cause major issues with multiple clients behind one.
All in all, TCP is a lot more stable accommodating such even if it has to deal with lost packets.
When used properly UDP has no more difficulty going through firewalls than TCP.
Originally by: Trishan
No, that's a very wild generalization. Nowadays TCP is reliable enough, and it depends on whether the particular game can still work fine if it misses packets.
Reliability has nothing to do with it... you want UDP so you can control the retransmits yourself and avoid wasting more network bandwidth on obsolete data.
Originally by: Danzir Kasnov Regarding using UDP.
As I understand CCP's policy with eve is to keep state information 100% accurate. Using UDP as has been mentioned means not all packets will end up necessarily being transmitted so the state information could become inaccurate. This is the main reason CCP have stuck with the more robust TCP protocol.
I'd be interested to hear a network dev comment on this topic and specifically about 1mg packets. Surely the main state information can be condensed better than that. You need a fair few coordinates, and a fair few variables associated with yourself and your targets, but your not talking megabytes here...
It becomes even more inaccurate with TCP since when a packet is dropped, that same information must be retransmitted even if there is newer, more accurate information available. Retransmitting the old information just delays the new information even more.
And there are no 1 meg packets; the original poster was confused.
|

Dr Slaughter
Rabies Inc.
|
Posted - 2008.01.18 12:08:00 -
[34]
Originally by: Gaogan And there are no 1 meg packets; the original poster was confused.
This
UDP would put extra work on the Proxy nodes so CCP would likely need to add more of them to the mix. I wonder how the location of players on proxies effects lag at the client and traffic at the node. I guess node to proxy communication would always be TCP based (and not really drop anything as they're probably on their own gigabit+ switched network).
CCP this is not the nerf you are looking for...
[a image was here once but it went away] |

Yuki Nagato
GoonFleet GoonSwarm
|
Posted - 2008.02.20 04:54:00 -
[35]
bump
|
| |
|
| Pages: 1 [2] :: one page |
| First page | Previous page | Next page | Last page |