Server stacking feature suggestion

[kilrogg]

Hi !
I would like to recommend a new feature for future builds of TeamSpeak.

I think stackable servers would benefit every user of teamspeak, especially the ones behind routers with limited bandwith available.

The basic idea is to be able to join a TS server with another ts server and to be logged in e.g. on your home teamspeak-server which is itself connected (globally or on a channel basis) to an external ts server.

That way it'd be possible to limit incoming traffic to a minimum, because each sentence spoken only has to be transferred ONCE to the internal TS server and is then distributed to each listener over internal fast-ethernet.

What do you think ??

Greets
Kilrogg

[Piglith]

I think this would be very simular to the IRC network ftp://ftp.irc.org/irc/docs/rfc2810.txt

3. Architecture

An IRC network is defined by a group of servers connected to each
other. A single server forms the simplest IRC network.

The only network configuration allowed for IRC servers is that of
a spanning tree where each server acts as a central node for the rest
of the network it sees.

1--\
A D---4
2--/ \ /
B----C
/ \
3 E

Servers: A, B, C, D, E Clients: 1, 2, 3, 4

Server to Server communications stream would have to be on its on port/link

This would solve traffic issues with a lot of servers by reducing the number of clients on any one perticular server

Wana knock the socks off the competition this would do it..... :D

[Brain]

Wana knock the socks off the competition this would do it.....
Not really, this is just a logical overlay over the physical network. If you could guarantee that the physical network would look exactly like the logical overlay you would have the leg up on the competition... however that is rather impossible unless you run your own MAN/WAN which probably nobody here does :)

[Piglith]

My point was only in the Server to Server (Server Peering)communications.

I think this would be very simular to the IRC network

[Brain]

There's also something else to take into consideration: latency. Real-time communication requires the lowest latency possible. If you start chaining servers you save bandwidth and traffic by paying with latency... Well, who would want to make that trade-off?

[Piglith]

If latency was an issue then by connecting to a the master server would be the way to go. If the Chaining function could be an option. Our clan uses TS for both. Real time Gaming Chat and just for General chat. So having the ablity to connect to a peer server would still help in the general chats.

Right now if someone uses voice activation and you talk over the person you can hear the echo. So I'm assuming the latencey with TS is currently only about 1.5 seconds now. With with the right design the peering would only hopefuly be .5 to 1 seconds addition... Something in a General chat you could live with.

[Brain]

I agree, in general chat latency is not that much of a problem unless it gets too long, say 5 seconds and more.
However for gaming chaining should be avoided to get minimum latency.

Well, I can deliver the great speeches, I'm not in a position to depend on server chaining, when 8 people are on my clanserver then it is much ;)

[Peter]

Hmm,

server stacking/linking whatever you want to call it has been discussed many times, and I currently think that it would not be worth doing it. Latency is a major issue in voicecom, even for normal "chat" it is very disturbing already as high as it is, I would really not like to have it higher.
Also, teamspeak users (currently) are very small groups (say less than 100 people), that can easily be hosted by one decent server, there is no technical need for server stacking to be able to manage big groups - because groups of the size that could be a problem do not exist.
The only advantage I can see is that lines that are not really capable of hosting even small servers decently (ISDN/Cable/DSL) could be stacked to be able to hold say 15 or 20 members. But doing this is just a step in the direction of p2p connections (a direction I would currently rather not go).