也问socket

龙四 2010-05-25 10:15:47

要搞一个基于socket的的远程方法调用（RMI,WEBSERVICE,HTTP都很容易做到，这里不提）。

涉及到的问题：

1、可能会处于高压力状况，所以在客户端需要保持socket连接。而不是每调用一个方法重连一次

2、既然是在我的电脑上调你电脑上jvm上的方法，肯定涉及参数传递和结果（包括异常信息）返回

本人想法如下：

封装一个客户端，new客户端的时候连接ServerSocket，然后一直保持该连接，直到调用客户端封装的close方法才断开连接。方法的参数和返回结果肯定都是可以序列化的，我可以建一个类，包括需要调用的方法名，方法参数的Class[]和参数数组，传到客户端后通过反射调用服务器中的方法，得到结果后，再封装到一个类中，如是否调用成功，调用的返回值和异常，这就涉及一个问题，TCP/IP是保证顺序的，单线程没有问题，但是如果客户端多线程调用方法，服务器端接受调用请求可以无先后顺序，但接收端也没有返回值的先后顺序了。如此一来，此法不通，需要自定义应用报文，可能形如以下格式

开始标志(固定字节)|方法标志(是哪个方法调用的，由调用的时候临时生成，确保唯一，传到服务器，再传回来，固定字节)|报文总长度（固定字节）|报文内容（可变长度）|结束标志(固定字节)

然后在客户端起一个独立的线程专门接收和解析服务器的这个报文，并将解析后的对象存放到客户端的一个Map属性（key为方法标志，value为调用结果），然后某个客户端方法发送调用请求后不断遍历该Map，直到找到调用结果或某种条件（如超过多长时间仍然没有找到）结束。

不知道各位牛人们有什么建议抑或有更好的想法？

...全文

194 25 打赏收藏转发到动态举报

写回复

用AI写文章

25 条回复

切换为时间正序

请发表友善的回复…

发表回复

lwwit 2010-05-26

打赏
举报

学习。。。。。。。。

龙四 2010-05-26

打赏
举报

tcp没问题，但是是个jar包都有稳定性问题，毕竟接口代码都是人写的，在没有得到充分检验之前是不敢乱用的

去瞧瞧xsocket

[Quote=引用 23 楼 moshalanye 的回复:]

你如果是需要一个更低层次的框架，也可以选择xsocket。

至于stable

tcp本来是就稳定的

软体自身的稳定策略是跟框架选择无关的吧
[/Quote]

龙四 2010-05-25

打赏
举报

不用考虑安全问题

“如果做集群，是需要有一个任务注册服务的，真正的任务处理应该在不同的机器上。”

这个容易出现单点故障，不能同时实现负载均衡和灾难恢复

[Quote=引用 10 楼 moshalanye 的回复:]

引用 8 楼 ticmy 的回复:
我可以将对象转换成byte[]后通过base64编码成字符

文本协议是协议层面的问题，安全是安全方面的。

如果楼主考虑安全的话，还需要提供一个安全的层，如果是安全度比较高的加解密，消息更严谨点是要考虑使用byte来做，设定安全消息的加密方式，消息体长度。
但如果仅仅是base64就完全没有必要了（base64最好使用乱序后的key）。
这……
[/Quote]

宁静-夏天 2010-05-25

打赏
举报

[Quote=引用 8 楼 ticmy 的回复:]
我可以将对象转换成byte[]后通过base64编码成字符
[/Quote]

文本协议是协议层面的问题，安全是安全方面的。

如果楼主考虑安全的话，还需要提供一个安全的层，如果是安全度比较高的加解密，消息更严谨点是要考虑使用byte来做，设定安全消息的加密方式，消息体长度。
但如果仅仅是base64就完全没有必要了（base64最好使用乱序后的key）。
这个要看安全的需求了。你是服务如果不太怕别人抓就无所谓了。考虑稳定可能更重要。加解密挺耗cpu的。特别CBC模式加解密。

如果做集群，是需要有一个任务注册服务的，真正的任务处理应该在不同的机器上。
任务处理服务具备以下能力：
1.不论监听的port有几个，统一把请求发送到注册服务server。
2.服务心跳监察，确认服务的机正常。
3.考虑每个任务处理进程中的任务队列的饱和度。（负载的考虑，每太机器的饱和度和机器自身性能有关，自己设定标准）。
4.当所有的任务机器都任务饱和的情况下，需要对请求进行通知，告知服务忙请重试。
已经发送任务机，也需要告知请求者正在处理。

宁静-夏天 2010-05-25

打赏
举报

你如果是需要一个更低层次的框架，也可以选择xsocket。

至于stable

tcp本来是就稳定的

软体自身的稳定策略是跟框架选择无关的吧

liuzhengkang 2010-05-25

打赏
举报

呵呵，不错啊，帮顶了。
如果对实时性要求较高的话，就使用阻塞模式吧。
如果是长连接的话，就启个“心跳”线程，定时发送心跳包，在断开的时候重连。
或许你可以在定义两个先进先出的消息队列（一个用于发送，一个用于接收），并加锁以确保消息队列线程安全。
服务端收到消息后，可以即刻返回简短的消息回执，以便客户端知道是否已被接收。

龙四 2010-05-25

打赏
举报

我可以将对象转换成byte[]后通过base64编码成字符

[Quote=引用 4 楼 moshalanye 的回复:]

修改：
1.非自定义协议尽量使用文本协议
改为
1.自定义协议尽量使用文本协议
[/Quote]

龙四 2010-05-25

打赏
举报

1.楼主是否到了非要自己定义协议的地步。
首先感谢关注！这个已经是必须的了

2.楼主的需求是否到了必须自己来完成server端开发的地步。server端考虑的问题多，不仅仅是楼主考虑的这些了。楼主还要考虑是采用nio模式或者阻塞模式，考虑心跳监控连接有效...，机器负载问题，大负载处理问题。
服务器端的服务已经是现成的，只需要加上socket协议进行处理
机器没问题，基本会是8C16G或者更好，还可做集群

服务器端还有什么其他方面的注意事项吗？真项目不敢大意，动手之前尽量考虑周全。不知道阁下是否有demo或者伪代码之类的可以拿来观摩观摩？

[Quote=引用 3 楼 moshalanye 的回复:]

（注：我是菜鸟！不是牛人！）

感觉楼主考虑的都是对的，但是我觉得你是在自己做协议，我也做过简单的通讯协议方面开发，但那次是必须自定协议情况(由于某个原因)。

1.楼主是否到了非要自己定义协议的地步。
2.楼主的需求是否到了必须自己来完成server端开发的地步。server端考虑的问题多，不仅仅是楼主考虑的这些了。楼主还要考虑是采用nio模式或者阻塞模式，考虑心跳监控连接有效...……
[/Quote]

龙四 2010-05-25

打赏
举报

感谢关注

UDP要自己处理报文顺序和完整性，不知道DatagramSocket有没有做过封装？
数据完整性是首要的

[Quote=引用 2 楼 paullbm 的回复:]

1).为什么不使用基于UDP协议，让服务端扮演一个报文转发的角色？
2).在自定义报文中，你可以添加源地址、目的地址、服务器地址的信息。服务端和客户端基于此三个地址按照一定规则(由你制定)进行数据交互即可！
[/Quote]

rsl189 2010-05-25

打赏
举报

看看先！

宁静-夏天 2010-05-25

打赏
举报

修改：
1.非自定义协议尽量使用文本协议
改为
1.自定义协议尽量使用文本协议

宁静-夏天 2010-05-25

打赏
举报

（注：我是菜鸟！不是牛人！）

感觉楼主考虑的都是对的，但是我觉得你是在自己做协议，我也做过简单的通讯协议方面开发，但那次是必须自定协议情况(由于某个原因)。

1.楼主是否到了非要自己定义协议的地步。
2.楼主的需求是否到了必须自己来完成server端开发的地步。server端考虑的问题多，不仅仅是楼主考虑的这些了。楼主还要考虑是采用nio模式或者阻塞模式，考虑心跳监控连接有效...，机器负载问题，大负载处理问题。

对于两个问题我会选择的做法。
1.非自定义协议尽量使用文本协议，测试和开发难度都会减少。最好能基于server服务的通讯协议进行扩展。
2.使用现存的server端，例如：mina(nio实现)，或者你自己直接使用（nio、http、...）注册请求，搭建线程池，提供任务处理器...,这样比自己纯写socket要稳定的多。开发量也会很多。

负载问题策略处理还是需要自己来。不知道你的server是否存在分布式设计。