通过已知端口进行服务器间通信
我们的产品系统由一台IIS 6.0服务器组成，后面是Java SOA服务器，两者后面都是Oracle数据库服务器。
由于各种原因，我们需要一个在 Java SOA 服务器上运行的 Windows 服务，用于存储与 GUID 关联的不透明 blob。下面是该界面的简化版本：
interface IBlobService
{
void PutBlob(Guid key, byte[] data);
byte[] GetBlob(Guid key);
}
IBlobService 的主要用户是运行在 IIS 服务器上的 Web 前端。我们可以通过自定义端口使用 WCF 或 .NET 远程处理来在服务器之间进行通信。然而，我们的申请需要遵守严格的认证要求。我们非常愿意使用已知端口进行通信，而不是自定义端口。
我们不能使用命名管道，因为我们需要在服务器之间进行通信。 我们曾考虑使用 MSMQ，因为它使用已知端口，但 MSMQ 将消息大小限制为 4 MB。我们需要传输的数据远不止于此——至少达到 60 MB。
.NET 还公开了哪些其他功能（如果有），可以允许服务器之间通过已知端口进行通信？
Our product system consists of an IIS 6.0 server, behind which is a Java SOA server, behind both of which is an Oracle database server.
For various reasons, we need a windows service running on the Java SOA server that stores opaque blobs associated with GUIDs. Here is a simplified version of the interface:
interface IBlobService
{
void PutBlob(Guid key, byte[] data);
byte[] GetBlob(Guid key);
}
The main user of the IBlobService is the web front-end running on the IIS server. We could use WCF or .NET remoting over a custom port for communication between the servers. However, our application is subject to strict accreditation requirements. We would highly prefer to use a known port for communication, rather than a custom port.
We can't use named pipes, because we need to communicate between the servers.
We had considered using MSMQ, as it uses a known port, but MSMQ limits message size to 4 MB. We need to transfer far more than that -- up to 60 MB at least.
What other capabilities (if any) does .NET expose that would allow communication between servers via a known port?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果 MSMQ 是我选择的工具，我会将数据分块并重新组合。
消息正文的内容是不透明的，因此每个块都可以包含 id、序列、大小和 CRC 等数据。
您可能需要考虑 WCF 二进制流。请参阅 MSDN 中的这篇文章： http://msdn.microsoft.com/en-us /library/ms733742.aspx
If MSMQ is the facility of choice, I would chunk the data and reassemble it.
The contents of your message body is opaque, so including with each chunk data such as id, sequence, size, and a CRC is all possible.
You might want to consider WCF binary streams. See this article from MSDN: http://msdn.microsoft.com/en-us/library/ms733742.aspx
如果您使用 WCF，则可以使用 HTTP/HTPS。您还可以在您喜欢的任何端口上使用原始 TCP。例如，仅仅因为端口 80 是标准 http 端口并不意味着您不能在该端口上运行其他协议，只要服务器尚未使用它即可。
Well if you are using WCF you could use HTTP/HTPS. You could also use raw tcp on whatever port you like. e.g. just because port 80 is the standard http port doesn't mean you cannot run some other protocol on that port, so long as the server isn't using it already.
这个答案并没有解决问题中的问题，而是提出了一种避免该问题的替代方法。
经过深思熟虑，不要求blob服务作为windows服务运行。相反，可以在 Java 应用程序服务器中托管一个实现数据 RESTful 接口的普通 Java servlet。这将绕过 SOAP 堆栈和 XML 开销，同时利用 Java 应用程序服务器的监控功能。
数据可以用 a 存储
，然后用 a 检索，
其中返回
This answer does not address the problem in the question but presents an alternative approach that avoids the problem.
After deliberation, it is not a requirement that the blob service run as a windows service. Instead, a plain Java servlet that implements a RESTful interface to the data could be hosted in the Java application server. This would bypass the SOAP stack and XML overhead, yet leverage the supervisory capability of the Java application server.
Data can be stored with a
And later retrieved with a
Which returns