Java TCP 服务器-客户端设计解决方案

发布于 2024-12-05 21:55:52 字数 437 浏览 3 评论 0原文

我正在开发一个高度面向对象的解决方案(即,我想要尽可能少的耦合,大量的可重用性和模块化代码,充分利用设计模式,干净的代码等)。我目前正在实现该应用程序的客户端-服务器方面,并且我对此很陌生。我知道如何使用套接字,以及如何发送和接收流。但是,我不确定实际上如何设计我的解决方案。

TCP Java 解决方案有哪些模式(如果有)?我将通过网络发送大量序列化对象,如何处理不同的请求/对象?事实上,我如何处理请求本身?我是否将发送的每个对象包装在另一个对象内,然后当对象到达时我将其解析为“命令/请求”,然后相应地处理其中包含的对象?我正在努力解决的正是这种总体设计。

所有在线教程似乎都是标准的回显服务器,用于发回客户端发送的文本。这些仅在了解实际套接字时有用,但在应用于实际情况时没有用。很多 case 语句和 if 语句看起来开发很差。有什么想法吗?我宁愿在这个阶段不使用框架。

干杯,

蒂姆。

I'm in the process of developing a highly object-oriented solution, (i.e., I want as little coupling as possible, lots of reusability and modular code, good use of design patterns, clean code, etc). I am currently implementing the client-server aspect of the application, and I am new to it. I know how to use Sockets, and how to send streams and receive them. However, I am unsure of actually how to design my solution.

What patterns (if any) are there for TCP Java solutions? I will be sending lots of serialized objects over the network, how do I handle the different requests/objects? In fact, how do I handle a request itself? Do I wrap each object I'm sending inside another object, and then when the object arrives I parse it for a 'command/request', then handle the object contained within accordingly? It is this general design that I am struggling with.

All the tutorials online just seem to be bog-standard, echo servers, that send back the text the client sent. These are only useful when learning about actual sockets, but aren't useful when applying to a real situation. Lots of case statements and if statements just seems poor development. Any ideas? I'd much rather not use a framework at this stage.

Cheers,

Tim.

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

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

发布评论

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

评论(3

放血 2024-12-12 21:55:52

考虑使用比 TCP/IP 更高级别的协议,不要重新发明轮子。 rmi 是一个不错的选择,您应该能够找到关于它的好教程。

Consider using a higher level protocol then TCP/IP, don't reinvent the wheel. rmi is a good option and you should be able to find good tutorials on it.

给我一枪 2024-12-12 21:55:52

我建议您要么使用 RMI,要么详细查看它,以便确定如何以不同的方式做事。至少我建议您在尝试自己动手之前先尝试一下 RMI,看看它是如何工作的。

I suggest you either use RMI, or look at it in details so you can determine how you would do things differently. At a minimum I suggest you play with RMI to see how it works before attempting to do it yourself.

临风闻羌笛 2024-12-12 21:55:52

如果高性能和低延迟不是主要要求,那么只需使用现有的解决方案。
如果您决定使用 rmi,而不是考虑使用带有 EJB 的 J2EE - 它将为您提供基于 rmi 的事务管理。

否则,如果您需要极低的延迟,请查看在 TCP 之上使用自定义协议的现有解决方案的来源。
例如,OpenChord 发送序列化的请求和响应对象,而 Project Voldemort 在其少数操作中使用自定义消息。

If high performance and low latency aren't main requirements then just use existing solutions.
And if you decide to use rmi than consider using J2EE with EJB - it'll provide you a transaction management on top of rmi.

Otherwise if you need extremely low latency take a look on sources of existing solutions that use custom protocols on top of tcp.
For example OpenChord sends serialized Request and Response objects and Project Voldemort uses custom messages for its few operations.

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