我怎样才能实现一个IRC服务器“拥有”？ 昵称？
最近，我一直在阅读 IRC 协议（RFC 1459、2810-2813），并且我正在考虑实现我自己的服务器。
我不一定要严格遵守 IRC 协议（毕竟我这样做是为了好玩），但我喜欢它的一件事是网络可以透明地由多个服务器组成。
该协议或 IRC 规范有很多我不喜欢的地方。 首先，昵称不属于任何人。 虽然像 NickServ 这样的服务存在，但它们不是官方协议的一部分。 另一方面，正确地实现像 NickServ 这样的东西有点违背了分发的目的（即，NickServ 会在一个地方运行，并且有一个数据存储） ）。
我希望有一种方法可以在每个服务器的基础上管理昵称。 这样做的问题是，如果您有两台注册了昵称的服务器，然后它们连接起来，则可能会发生冲突。
有没有一种方法可以避免这种情况，而不使用一个中央数据存储？ 也就是说：是否可以保持服务器松散连接（使得它们各自作为独立实体存在，但也可以相互连接）并保持昵称之间的唯一性？
我意识到这个问题很模糊，但我想不出更好的措辞方式。 我更多地寻求建议，而不是实际的是/否答案。 因此，如果有人对如何在网络中实现昵称唯一性同时仍保持服务器独立性有任何想法，我将有兴趣听到它。 请注意，完全没有必要严格遵守 IRC 协议。 我可以毫无问题地改变事情以适应我的目的。 :)
Recently, I've been reading up on the IRC protocol (RFCs 1459, 2810-2813), and I was thinking of implementing my own server.
I'm not necessarily looking into adhering religiously to the IRC protocol (I'm doing this for fun, after all), but one of the things I do like about it is that a network can consist of multiple servers transparently.
There are a number of things I don't like about the protocol or the IRC specification. The first is that nicknames aren't owned. While services like NickServ exist, they're not part of the official protocol. On the other hand, implementing something like NickServ properly kind of defeats the purpose of distribution (i.e. there'd be one place where NickServ is running, and one data store for it).
I was hoping there'd be a way to manage nicknames on a per-server basis. The problem with this is that if you have two servers that have some registered nicknames, and they then link up, you can have collisions.
Is there a way to avoid this, without using one central data store? That is: is it possible to keep the servers loosely connected (such that they each exist as an independent entity, but can also connect to one another) and maintain uniqueness amongst nicknames?
I realize this question is vague, but I can't think of a better way of wording it. I'm looking more for suggestions than I am for actual yes/no answers. So if anyone has any ideas as to how to accomplish nickname uniqueness in a network while still maintaining server independence, I'd be interested in hearing it. Note that adhering strictly to the IRC protocol isn't at all necessary; I've got no problem changing things to suit my purposes. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您不关心严格实现 IRC 服务器，而是实现一个类似 IRC 的分布式消息系统，那么有一个简单的解决方案，但是不完全是 IRC。
简单的解决方案是使用“nick@host”形式的昵称，就像电子邮件一样。 因此，我的昵称不仅仅是“mipadi”，还可以是“[email protected] ]”。 因此，我只在您的服务器上注册，但是当您的服务器与其他服务器链接形成另一个大型聊天网络时，您可以轻松地将所有用户名联合在一起。 otherserver.net 上可能有一个“mipadi”，但是我们的昵称变成了“[email& nbsp； protected]”和“[电子邮件受保护]”，以及一切都很酷。
当然，这与 IRC 有很大的偏差。 :)
There's a simple solution if you don't care about strictly implementing an IRC server, but rather implementing a distributed message system that's like IRC, but not exactly IRC.
The simple solution is to use nicknames in the form "nick@host", much like email. So instead of merely being "mipadi", my nickname could be "[email protected]". So I register with just your server, but when your server links up with others to form another a big ole' chat network, you can easily union all the usernames together. There might be a "mipadi" on otherserver.net, but then our nicknames become "[email protected]" and "[email protected]", and everything is cool.
Of course, this deviates a good deal from IRC. :)
他们必须互相了解。 否则，您无法阻止昵称的共享。 如果是，您只需在后端传输更新即可。 为了防止同时注册，您需要一个事务系统来阻止、请求所有其他服务器的许可并做出响应。
为了防止在中断期间同时注册，您别无选择，只能为注册添加时间戳，并删除除最后一个（或真正同步的随机）注册的昵称副本之外的所有副本。
考虑到这些服务器最初并未合并，这并不是很漂亮。
They have to be aware of each other. If not, you cannot prevent the sharing of nicknames. If they are, you simply need to transfer updates on the back-end. To prevent simultaneous registrations, you need a transaction system that blocks, requests permission from all other servers, and responds.
To prevent simultaneous registrations during outages, you have no choice but to timestamp the registration, and remove all but the last (or a random for truly simultaneous) registered copy of the nick.
It's not very pretty considering these servers aren't initially merged in the first place.
如果您的服务器实例相互信任，您仍然可以在没有中央实例的情况下实现昵称所有权。
如果您不能信任您的服务器，那么事情会变得更加困难，因为服务器可以轻松地声明每个用户名，甚至声明每个用户名的最旧注册。
You could still implement nick ownership without a central instance, if your server instances trust each other.
If you can't trust your servers, then it'll get a lot harder, as a servers could easily claim every username and even claim the oldest registration for each one.
由于您正在尝试提出新的东西，因此想到的想法就是在服务器外部通信时将服务器特有的内容作为昵称的一部分。 因此，如果您想向不同服务器上的用户发送消息，您可能会拥有类似 user@server 的内容。
如果您不需要它们完全独立，您可能需要考虑创建某种多主复制帐户数据库。 每个服务器都存储帐户数据库的完整副本，并且每个服务器都可以创建新帐户，并将其尽可能复制到其他服务器。 不过，有时您可能仍然需要处理碰撞。
Since you are trying to come up with something new, the idea that springs to mind, is simply including something unique about the server as part of the nick name when communicating outside of the server. So if you want to message a user on a different server you might have something like user@server
If you don't need them to be completely separate you might want to consider creating some kind of multiple-master replicated database of accounts. Where each server stores a complete copy of the account database, and each server can create new accounts which will be replicated to other servers as possible. You'll probably still have to deal with collisions on occasion though.
服务不是官方协议的一部分，因为它们与协议无关。 他们是有权限的机器人。 没有理由不能在每台服务器上运行一个，但这确实使它们更难维护。
如果您要走这条路，我可能会建议常用的“多主”数据库复制技术。 如果一个节点收到写入（在您的情况下，创建或更新一个新用户等），它会将数据发送到所有其他节点。 不过你必须要小心。 如果一个节点在其他节点获得更新时处于离线状态，则它将需要知道在重新连接时重新同步。
另一种技术与上述相同，但相反。 数据仅在需要时在节点之间交换。 例如，如果用户尝试登录没有数据的节点，它将查询其他节点并发出移动命令以将所有数据获取到该节点。 这可能比复制版本的痛苦要小，但如果有人在与包断开连接的节点上注册以获得重复的缺口，则网络分裂可能会出现严重问题。
消除网络分裂问题的一种技术是让聊天节点及其机器人具有网络分裂意识。 当它们被分割时，它们可能不应该允许任何写入操作......但是如果您分割很多，这可能会影响您的网络。
您还必须询问这可能或可能不安全。 IRC 网络节点是为了性能而分布的，但它们并不“安全”。 因此，服务机器人通常集中运行，以对其运行保持最终控制。 如果您分发机器人并且远程节点被黑客攻击，他们可能有权访问整个用户数据库（取决于型号）。
Services are not part of the official protocol because they've nothing to do with the protocol. They're bots with permissions. There's no reason why you couldn't have one running on each server but it does make them harder to maintain.
If you were to go down that path, I would probably suggest the commonly used "multiple master" database replication technique. If one receives a write (in your case, a new user is created or updated, etc) it sends the data to all the other nodes. You'll have to be careful though. If one node is offline when the others get an update, it will need to know to resync on reconnection.
Another technique would be as above but in reverse. Data is only exchanged between nodes when it's needed. Eg if a user tries to log in on a node where there's no data for it, it'll query the others and issue a move order to get all the data to that one node. This is potentially less painful than the replication version but there could be severe problems in netsplits if somebody signs up on a node disconnected from the pack for a duplicate nick.
One technique to nullify the problems of netsplits would be to make chat nodes and their bots netsplit-aware. When they're split, they probably shouldn't allow any write actions... But this could impact on your network if you're splitting lots.
You've also got to ask how secure this might or might not be. IRC network nodes are distributed for performance but they're not "secure". Because of this, service bots are usually run centrally to keep ultimate control over their running. If you distributed the bots and remote node got hacked, they'd potentially have access to the whole user database (depending on the model).