3 ms·
I'm not sure what distinction you're trying to draw here. Calling the process that handles communication between users a "server" was already common practice ba
by AlotOfReading 3y ago
I'm not sure what distinction you're trying to draw here. Calling the process that handles communication between users a "server" was already common practice back when IRC was standardized in 1993 (where discord gets the term from). It even appears in the original jargon file, so that definition was common long before even that.
- xigoi 3y agoYes, I don't disagree with this definition. But a Discord “server” is not analogous to an IRC server.
- charcircuit 3y agoAn IRC server has a collection of channels. A discord server has a collection of channels. It is simple as that. IRC servers don't refer to a single physical server either since IRC servers supported federation allowing multiple servers to act as a single server. There is no need to be so strict on the definition of server considering how loose its usage was already with IRC.
- saurik 3y agoNo: an IRC network is a collection of channels. A network is then made up of numerous servers. In IRC parlance a server always in fact did explicitly mean a specific individual server and I would be shocked if you found anyone who hadn't used IRC for more than even a day or so that tried to call, say, EfNet a "server".
- akkartik 3y ago<moleman>I call EfNet a server.</moleman>
- akkartik 3y agoIn fact I see this block in my .irssi/config: servers = ( ... { address = "irc.efnet.net"; chatnet = "EFNet"; port = "6667"; }, ... );
- saurik 3y agoThat is a specific hostname and is in essence a "server" (though the existence of irc.efnet.net is special in that it is a DNS load balancer address that selects a random server) and isn't EFNet; the concept of "EFNet", in contrast, is being called a "chatnet" in that configuration file, not a server. You might have multiple servers configured for the same network, and irssi will attempt to round-robin the connection between them if they fail. If you want a list of networks in irssi, you use /network list; if you want a list of servers you use /server list. FWIW, IRC barely exists anymore. To the extent to which to does it has been massively simplified. It used to be that there were massive collections of servers for most networks run by tons of different people, and often if you ran an isolated server for a single-server network people would show up ply you to add their server to your network. I can see how someone who only casually uses IRC and only semi-recently (in the past decade or two) might be left with a really limited or even confused understanding of the lingo. So like, sometimes networks did have these DNS round-robin load balancer addresses, and I could see someone getting confused by that for a bit. But, they weren't used all that often other than as a server discover mechanism, because--for a number of reasons I will list a few of--it mattered greatly what server you were actually on... enough so that, if you were to actually to use IRC much at all, it would become very very clear that a network and a server are not somehow interchangeable terms. 1) The Internet itself and the software we were using was flakey enough that you would routinely encounter a "netsplit", wherein people who were on one half of the network could still talk to each other but people on the other would see you all disconnect. (This was also used by people to try to attack and take over channels by denial of service attacking specific servers in the network as the behavior of re-merging channels often gave you moments where you could take chanops.) 2) The latency across the Internet was sometimes higher--particularly if you had to do multiple hops to get to the right server the user was on--and so people who were on the same server as each other had a lot better experience talking to each other. 3) The channel namespace using # was global to the network but many networks supported server-local channels that were prefixed with ##. If you were on a different server you would thereby not be able to see the same server-local channels. Nowadays, you wouldn't bother with most of this as, administratively, this is madness. The usual server-to-server protocol forms a DAG and so it doesn't actually provide any form of redundancy: your network feels about as stable as the least stable server (weighted by how close it is to the center of the graph). You also don't need lots of servers to try to distribute the connection load, and the core Internet latency isn't a big deal anymore.
- deleted 3y ago[deleted]