如上所述，削减服务器实现。我使用 jabberd 1.x，它使用 XML 文件进行配置。我通过提供已预先填充的名册 XML 文件将其与我们的用户数据库集成。理论上，用户可以弄乱他们的名单，但他们会被服务器覆盖。实际上，这并没有发生，因为客户端软件阻止了它。您可能需要比这更进一步，但我相信现在有足够灵活的服务器来允许它。
One option that you've missed is something based on SIP. SIP and XMPP have always been considered to overlap somewhat, although XMPP seems to have won out for the specific case of instant messaging. I don't have any knowledge of IM over SIP.
I would go with XMPP because:
Server implementations are mature, which means that you can change the server later if you need to without affecting the rest of your infrastructure.
There are lots of ready-made clients, including ones suitable for your bank's customers (AJAX) and ones suitable for your bank managers (desktop).
IM over XMPP is common. The most common case for SIP is VoIP. If you try and get help with IM over SIP, most SIP experts will tend to know far more about voice than IM. If you try and get help with IM over XMPP, that's exactly what XMPP experts deal with all the time. The same applies to documentation: SIP documentation will tend to be geared around VoIP.
Using a solution that doesn't support XMPP or SIP is a dead end in terms of development, in my opinion. Even Google and Facebook are using XMPP now. XMPP appears to be the future-proof option now.
IRC is a many-to-many chat mechanism. There is DCC but that is mainly around establishing a one-to-one channel for communication. I think that if you did implement something based on IRC, you would spend a lot of your time pulling out the many-to-many function where you don't want it, and there won't be much else left, since you'd also have to replace the DCC implementation with something to go down AJAX/XmlHttpRequest/WebSockets instead.
If you ended up customising things more and more, XMPP is well-engineered, well-specified and a good base to start from. You could incrementally replace the web client, the desktop client and the server without disruption or headache.
Some possible caveats:
XMPP servers want to talk to other ones, since the protocol is designed to be federated. You need to make absolutely sure that this won't happen. XMPP normally talks on 5222 for client->server and 5269 for server<->server, but SRV is also used.
The same goes for whichever client you choose. You may need to cut it down to make sure that users cannot use functions that are common to more general use, such as adding and deleting users from the roster (and worse, outsiders on eg. GTalk managing to confuse and perhaps phish your customers).
The two biggest issues that I think you might have with XMPP are:
Managing users and rosters on the XMPP server, since they are mostly designed for general use and not a sandboxed environment. The server will tend to expect and allow the clients to register, set passwords etc, whereas you presumably want to both prevent this from happening and manage everything yourself.
Cutting out all the extra features that could cause problems. You presumably don't want your customers speaking to each other, transferring files about etc.
I have set up and maintained a private multi-site, multi-server, private XMPP installation spanning a number of connected customers, back in about 2002. The main things I had to do were:
Getting a server implementation cut down as mentioned above. I used jabberd 1.x, which used XML files for configuration. I integrated it with our user database by supplying roster XML files already pre-populated. Users could in theory mess with their rosters, but they would get overwritten by the server. In practice this didn't happen because the client software prevented it. You will probably need to go a step further than this, but I believe there are servers flexible enough to allow it now.
Getting a client implementation that could be automatically pre-configured and not messed with. I selected and patched a specific client (Psi) to add a "lockdown" mode which could be used to remove all configuration-related UI elements, including roster management options. Configuration was instead automatically done by the server. Users would then have something simple that they did not have to configure and that could not go wrong. Something like this might work for your bank managers - it will save a lot on support.
发布评论
评论（2）
您错过的一个选项是基于 SIP 的选项。尽管 XMPP 似乎在即时消息传递的特定情况下胜出，但 SIP 和 XMPP 一直被认为有些重叠。我对 SIP 上的 IM 没有任何了解。
我会选择 XMPP，因为：
服务器实现已经成熟，这意味着您可以稍后根据需要更改服务器，而不会影响基础架构的其余部分。
有很多现成的客户端，包括适合您银行客户 (AJAX) 的客户端和适合您银行经理（桌面）的客户端。
基于 XMPP 的 IM 很常见。 SIP 最常见的情况是 VoIP。如果您尝试获取有关基于 SIP 的 IM 的帮助，大多数 SIP 专家往往对语音的了解远多于 IM。如果您尝试通过 XMPP 获取 IM 帮助，这正是 XMPP 专家一直在处理的问题。这同样适用于文档：SIP 文档往往以 VoIP 为中心。
在我看来，使用不支持 XMPP 或 SIP 的解决方案在开发方面是一个死胡同。甚至 Google 和 Facebook 现在也在使用 XMPP。 XMPP 现在似乎是面向未来的选择。
IRC 是一种多对多聊天机制。有 DCC，但主要是建立一对一的沟通渠道。我认为，如果你确实实现了基于IRC的东西，你会花很多时间在你不需要的地方拉出多对多功能，并且不会剩下太多，因为你' d 还必须用 AJAX/XmlHttpRequest/WebSockets 代替 DCC 实现。
如果您最终需要越来越多地自定义事物，XMPP 设计精良、规范明确，是一个良好的起点。您可以逐步替换 Web 客户端、桌面客户端和服务器，而不会造成中断或头痛。
一些可能的注意事项：
XMPP 服务器想要与其他服务器通信，因为该协议被设计为联合的。您需要绝对确保这种情况不会发生。 XMPP 通常在 5222 上进行客户端->服务器的通信，在 5269 上进行服务器<->服务器的通信，但也使用 SRV。
这同样适用于您选择的任何客户。您可能需要减少它，以确保用户无法使用更通用的功能，例如从名册中添加和删除用户（更糟糕的是，GTalk 上的外部人员设法迷惑并可能对您的客户进行网络钓鱼） .
我认为 XMPP 可能遇到的两个最大问题是：
管理 XMPP 服务器上的用户和名册，因为它们主要是为一般用途而不是沙盒环境而设计的。服务器倾向于期望并允许客户端注册、设置密码等，而您可能希望既防止这种情况发生又自己管理一切。
删除所有可能导致问题的额外功能。您可能不希望您的客户互相交谈、传输文件等。
早在 2002 年左右，我就已经建立并维护了一个私有的多站点、多服务器、私有 XMPP 安装，涵盖了许多连接的客户。我必须做的主要事情是：
如上所述，削减服务器实现。我使用 jabberd 1.x，它使用 XML 文件进行配置。我通过提供已预先填充的名册 XML 文件将其与我们的用户数据库集成。理论上，用户可以弄乱他们的名单，但他们会被服务器覆盖。实际上，这并没有发生，因为客户端软件阻止了它。您可能需要比这更进一步，但我相信现在有足够灵活的服务器来允许它。
获得一个可以自动预配置且不会混乱的客户端实现。我选择并修补了一个特定的客户端 (Psi)，以添加“锁定”模式，该模式可用于删除所有与配置相关的 UI 元素，包括名册管理选项。配置由服务器自动完成。然后，用户将获得一些简单的东西，他们不需要配置并且不会出错。这样的东西可能对您的银行经理有用 - 它将节省大量支持。
One option that you've missed is something based on SIP. SIP and XMPP have always been considered to overlap somewhat, although XMPP seems to have won out for the specific case of instant messaging. I don't have any knowledge of IM over SIP.
I would go with XMPP because:
Server implementations are mature, which means that you can change the server later if you need to without affecting the rest of your infrastructure.
There are lots of ready-made clients, including ones suitable for your bank's customers (AJAX) and ones suitable for your bank managers (desktop).
IM over XMPP is common. The most common case for SIP is VoIP. If you try and get help with IM over SIP, most SIP experts will tend to know far more about voice than IM. If you try and get help with IM over XMPP, that's exactly what XMPP experts deal with all the time. The same applies to documentation: SIP documentation will tend to be geared around VoIP.
Using a solution that doesn't support XMPP or SIP is a dead end in terms of development, in my opinion. Even Google and Facebook are using XMPP now. XMPP appears to be the future-proof option now.
IRC is a many-to-many chat mechanism. There is DCC but that is mainly around establishing a one-to-one channel for communication. I think that if you did implement something based on IRC, you would spend a lot of your time pulling out the many-to-many function where you don't want it, and there won't be much else left, since you'd also have to replace the DCC implementation with something to go down AJAX/XmlHttpRequest/WebSockets instead.
If you ended up customising things more and more, XMPP is well-engineered, well-specified and a good base to start from. You could incrementally replace the web client, the desktop client and the server without disruption or headache.
Some possible caveats:
XMPP servers want to talk to other ones, since the protocol is designed to be federated. You need to make absolutely sure that this won't happen. XMPP normally talks on 5222 for client->server and 5269 for server<->server, but SRV is also used.
The same goes for whichever client you choose. You may need to cut it down to make sure that users cannot use functions that are common to more general use, such as adding and deleting users from the roster (and worse, outsiders on eg. GTalk managing to confuse and perhaps phish your customers).
The two biggest issues that I think you might have with XMPP are:
Managing users and rosters on the XMPP server, since they are mostly designed for general use and not a sandboxed environment. The server will tend to expect and allow the clients to register, set passwords etc, whereas you presumably want to both prevent this from happening and manage everything yourself.
Cutting out all the extra features that could cause problems. You presumably don't want your customers speaking to each other, transferring files about etc.
I have set up and maintained a private multi-site, multi-server, private XMPP installation spanning a number of connected customers, back in about 2002. The main things I had to do were:
Getting a server implementation cut down as mentioned above. I used jabberd 1.x, which used XML files for configuration. I integrated it with our user database by supplying roster XML files already pre-populated. Users could in theory mess with their rosters, but they would get overwritten by the server. In practice this didn't happen because the client software prevented it. You will probably need to go a step further than this, but I believe there are servers flexible enough to allow it now.
Getting a client implementation that could be automatically pre-configured and not messed with. I selected and patched a specific client (Psi) to add a "lockdown" mode which could be used to remove all configuration-related UI elements, including roster management options. Configuration was instead automatically done by the server. Users would then have something simple that they did not have to configure and that could not go wrong. Something like this might work for your bank managers - it will save a lot on support.
这是很久以后的事了，一些更新的技术已经出现，即 WebRTC。
它允许音频/视频通话、以 P2P 方式传输数据，同时使用本机浏览器 API。
This is a lot later, and some newer technologies have emerged, namely WebRTC.
It allows audio/video calls, data transfert in a P2P fashion, while using native browser APIs.