【多文件自平衡云传输 五】---资源拥有者

资源拥有者功能

1.成为RMI服务器等待资源请求者的连接
2.根据请求者的节点信息以及分配资源的信息连接到资源请求者服务器并开始发送。

资源拥有者工作流程

在成为资源拥有者前，除了资源服务器拥有资源外，就没有任何服务器了。在资源请求者中说过了，请求完资源后会向注册中心注册资源，这样就正式成为一个资源拥有者了。在上述功能中其实已经谈到了，资源拥有者是开启了一个RMI服务器的，在得到请求者的请求后（RMI），会去连接发送者的资源接收服务器，根据资源分配信息开始发送就好了。

资源拥有者实现细节

资源拥有者对应的类，这里进行了基本配置并可以开启与关闭RMI服务器。这里有一个值得注意的地方，这里所有的方法以及成员都是静态的，为什么使用静态？
因为在我的底层框架中会去调用请求者请求的方法，但是在请求的方法中需要使用到以上所有的成员以及方法，这样就不行了，除非是使用一个内部类来实现接口方法。否则就只有全部使用静态的方法，那么直接get就可以得到我们要使用的任何成员。

这里是给上层app调用的并开启发送的一个类，这个类还是很朴素不需要讲解，下面讲解一下这里使用到的sender。这个类中是直接发送还是有一些注意的东西的。

这里的startSend是将所有的SectionHeader根据其文件id进行了一次排序，为什么需要这样？因为我们进行读写操作时会涉及到RandomAccessFile，而这个类是利用的系统资源，是有限的。所以需要我们用完就关闭，虽说我们在ResourceInfo进行分片后，每一个片段确实是按照文件id来存放的，但是以防以后更改了分片规则，所以在这这里还是进行一次排序。排序完毕后，开启了一次接收线程，对这个接收线程进行处理。

对每一个sectionHeader进行遍历，然后对这个sectionHeader的offset、len以及该文件对应的RandomAccessFile对该文件的指定位置和指定长度进行读取真实的文件信息，读取后进行发送。当遍历到的sectionHeader的文件id发生了变化，那么就说明上次已经是一个文件的最后一次发送了，所以就执行关闭RandomAccessFile的操作。遍历完毕后发送结束信息，并且一定要注意，因为我们是按照上一次遍历的文件id与这次的文件id的不同来进行关闭RandomAccessFile的，所以最后一次是不会进行关闭的，所以在最后我执行了最后一个文件的关闭操作。

这里就是多文件云传输的资源拥有者的所有。

总结

我们这里来进行一次总结并测试操作。
工作流程：
资源拥有者向注册中心进行注册，注册后资源请求者通过资源的id向资源注册中心请求资源拥有者地址列表。获取资源地址列表后，通过选择一个服务器来发送资源的信息（这也可以是app上层提供），得到信息后将资源进行分片。分片后将根据选择策略选择合适的资源节点成为服务器，并开启资源接收服务器。然后利用RMI向其发送资源片段信息。资源拥有者在获得信息后，根据RandomAccessFile以及SectionHeader去实际的读文件，读完后进行发送，发送完毕后发送一个END信息并关闭。
这里就不给出测试了，实际上应该还是app层提供文件信息，然后再是进行接收和发送过程，这里我做的获取resourceInfo只是为了测试使用。