server capacity higher

[andycooly]

hi is it just a rumor that servers can go up to 3550 now or is that just a rumor???

[Josie]

its just a rumor. its just delay buggs that make it look like they can carry that many people, they cant.. everyone get's dc'd instead.

[andycooly]

will it get higher at all or will 3500 b cap for a looonnnggg time?

[Josie]

loooong time!

[andycooly]

will the servers get less crowded lol

[JKMB]

The servers can hold about 10k people, Joymax limits this to 3.5k to optimize performance and minimlize lag, despite the irony that it lags anyway.

[Drew_Benton]

The servers can hold about 10k people, Joymax limits this to 3.5k to optimize performance and minimlize lag, despite the irony that it lags anyway.

There's a specific reason why Silkroad lags. It's not that their network code is poorly coded or their server hardware sucks, it's because the game uses TCP.

With the TCP protocol, any data that is sent from the client to the server or the server to the client is delivered reliably and in order. This means if the server sends the client a packet stream with the data [A][B][C][D], the client will receive and process the data as [A][B][C][D]. The catch to this though, is that as soon as one packet is lost, delayed, or corrupted, it is sent again. No more packet processing will be done until that missing packet is received. If A and B made it, C was lost and D made it, the game would wait for C before processing A, B, C, and D (assuming those 4 segments comprised the same game packet, movement, chat, etc..)

Silkroad is a server driven game, the client is only a shell. As a result, it will "lag" when it does not have the next set of data to process. Until the client receives the appropriate packets from the server, it won't do anything. You can verify this with any emu project, the client won't do anything on it's own until it receives the response from the server. So, when a packet is lost from their servers to your client, you get lag because the packet processing code is stalled.

On good days where there is a good connection to the server (consider data traveling from your country to Korea) lag isn't a big problem with very low packet loss. However, once network lines get disrupted anywhere along the way, that's when you start to get horrible lag delays and eventually disconnects form the server being out of sync with the client.

For this very fact and normal Silkroad performance, I would say the hardware JM has running SRO is nothing short of amazing. I'm guessing they have quite a large server farm servicing all of the servers. That's also why each server has multiple IP addresses. With TCP, each connection requires a specific socket connection. Once you start getting a lot of connections your computer will run out of ports or resources. By having multiple IP addresses for different servers, more resources are available to handle connections.

In short, there is nothing JM could really do to eliminate lag. They can alleviate it, but ultimately it depends on the network lines the data is traveling through with TCP. Having really good hardware helps a lot though.

Just thought I'd share

[chesticles]

+1 to Drew. God Damn I wish I was that tech savy. I mean I know computers but damn lol

[Annihilate]

The servers can hold about 10k people, Joymax limits this to 3.5k to optimize performance and minimlize lag, despite the irony that it lags anyway.

There's a specific reason why Silkroad lags. It's not that their network code is poorly coded or their server hardware sucks, it's because the game uses TCP.

With the TCP protocol, any data that is sent from the client to the server or the server to the client is delivered reliably and in order. This means if the server sends the client a packet stream with the data [A][B][C][D], the client will receive and process the data as [A][B][C][D]. The catch to this though, is that as soon as one packet is lost, delayed, or corrupted, it is sent again. No more packet processing will be done until that missing packet is received. If A and B made it, C was lost and D made it, the game would wait for C before processing A, B, C, and D (assuming those 4 segments comprised the same game packet, movement, chat, etc..)

Silkroad is a server driven game, the client is only a shell. As a result, it will "lag" when it does not have the next set of data to process. Until the client receives the appropriate packets from the server, it won't do anything. You can verify this with any emu project, the client won't do anything on it's own until it receives the response from the server. So, when a packet is lost from their servers to your client, you get lag because the packet processing code is stalled.

On good days where there is a good connection to the server (consider data traveling from your country to Korea) lag isn't a big problem with very low packet loss. However, once network lines get disrupted anywhere along the way, that's when you start to get horrible lag delays and eventually disconnects form the server being out of sync with the client.

For this very fact and normal Silkroad performance, I would say the hardware JM has running SRO is nothing short of amazing. I'm guessing they have quite a large server farm servicing all of the servers. That's also why each server has multiple IP addresses. With TCP, each connection requires a specific socket connection. Once you start getting a lot of connections your computer will run out of ports or resources. By having multiple IP addresses for different servers, more resources are available to handle connections.

In short, there is nothing JM could really do to eliminate lag. They can alleviate it, but ultimately it depends on the network lines the data is traveling through with TCP. Having really good hardware helps a lot though.

Just thought I'd share

aka they could know everything we do?...

[Ramrod]

Drew is correct. About a year ago I was getting heavy lag so I started looking into the reason why.

So I ran a traceroute and noticed that at a hop in Korea the latency (ms) went from about 100 to 500 in just one hop, and it was frequently dropping packets if I ran a ping to the SRO servers. I then proceeded with a packet capture running on my PC and saw how many TCP retransmissions their were for lost packets.

It's unfortunate that the servers are located so far away, and that once the packet leaves your network you have no control over how it will get to the destination. Unfortunately it is not uncommon to experience routing loops,cable cuts, and congestion within the Internet.