Java 中的网络通信选项(客户端/服务器)

发布于 2024-12-08 04:41:00 字数 199 浏览 0 评论 0原文

有 RMI(我认为它相对脆弱)、直接 Socket 连接(级别相当低)和字符串(虽然它看起来很可靠),但它似乎是隐喻的 PHP。

对于基于互联网的客户端/服务器通信,我有哪些不太基本的选项?有什么优点/缺点?我应该考虑哪些问题?第三方库建议很好,只要它们保持平台独立(即没有限制性的本机代码)。

寻找选项,而不是确定的答案,所以我将自己的要求细节留空。

There is RMI, which I understand to be relatively fragile, direct Socket connections, which is rather low level, and Strings, which while about as solid as it gets seems to be the metaphorical PHP.

What less basic options do I have for internet based Client/Server communication ? What are the advantages/disadvantages ? What are some concerns I should take into consideration ? Third party library suggestions are fine, as long as they stay platform independent (i.e. no restrictive native code).

Looking for options, not a definite answer, so I'm leaving the details of my own requirements blank.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

揽月 2024-12-15 04:41:00

当您指定“基于互联网”时,对于基于 HTTP 的 RESTful 方法(我强调了您应该考虑的一些问题):

优点:

  • 您可以使用/滥用无数的网络层之一服务器端的框架(例如Spring MVC播放!
  • 底层工作已经完成 在客户端 (Apache HTTPClient)
  • 纯文本协议很容易在线调试
  • 大量工具可帮助您调试交互(例如SoapUI) - 您可以假装是客户端或服务器,因此独立开发,直到另一端准备好
  • 使用 >知名港口 (80/443) 使穿透公司防火墙变得更加容易

缺点:

  • 有一个相当重要的假设,即服务器将完成大部分工作 - 如果您的模型是“颠倒的”,那么采用 RESTful 可能没有多大意义
  • 原始性能将低于基于位在线套接字的方法
  • 纯文本协议很容易嗅探线路(SSL 可以解决这个问题)

As you specified "internet based", there's a lot to be said for an HTTP-based, RESTful approach (I've highlighted some concerns you should consider):

Pros:

  • You can use/abuse one of the myriad web-tier frameworks for the server side (e.g. Spring MVC, Play!)
  • The low-level work has been done on client-side (Apache HTTPClient)
  • Plain-text protocol is easy to debug on the wire
  • Tons of tools available to help you debug the interactions (e.g. SoapUI) - you can pretend to be client OR server and so develop in isolation until the other end is ready
  • Using a well-known port (80/443) makes punching through corporate firewalls a whole lot easier

Cons:

  • There's a fairly major assumption that the server will be doing the lion's share of the work - if your model is "inverted" then it might not make much sense to be RESTful
  • Raw performance will be lower than a bits-on-the-wire socket-based approach
  • Plain-text protocol is easy to sniff on the wire (SSL can remedy this)
猫九 2024-12-15 04:41:00

“相对脆弱”是什么意思? RMI 的问题在于它是一个狭窄基础上的大型上层建筑,特别是它对 DNS 和对象序列化有很大的依赖。离芯片越近,程序就越不“脆弱”,但需要编写的代码也就越多。这是一个权衡。我不是 RMI 的单眼支持者,尽管我写过一本关于 RMI 的书,但“脆弱”这个词太重了。它做了它该做的事,而且做得相当好。如果您需要大规模的可扩展性,RMI/IIOP 在许多方面都做得更好。如果您对世界的看法是最多一次远程方法调用而没有太多安全性,那么 RMI/JRMP 将为您提供它。你离这个模型越远,应用起来就越困难。

What does 'relatively fragile' mean? The issues with RMI have to do with it being a large superstructure on a narrow foundation, and specifically that it has a large reliance on DNS and Object Serialization. The closer you are to the silicon, the less 'fragile' any program becomes, but the more code you have to write. It's a tradeoff. I'm not a one-eyed RMI supporter, despite having written a book about it, but 'fragility' is too strong a word. It does what it does, and it does that reasonably well. RMI/IIOP does it even better in many respects if you need large-scale scalability. If your view of the world is an at-most-once remote method call without too much security, RMI/JRMP will give it to you. The further you get from that model the harder it becomes to apply.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文