Java代写代考

项目说明 目的 通过构建聚合和分发ATOM提要的简单系统，以了解构建客户端/服务器系统所需的条件。 介绍 随着要跟踪的事物数量的增加，信息管理和跟踪变得更加困难。对于大多数用户而言，他们希望跟踪的网页数量非常多，如果他们不得不记住手动检查所有内容，那么当您疲倦或忙碌时，很容易忘记一两个网页。输入联合，该机制使网站可以将摘要发布为供您签名的提要，以便在发生新情况时收到通知，然后，如果您感兴趣，可以去看看。在联合组织领域中，最初的努力包括开发RSS协议系列，但实际上这些协议尚未标准化。ATOM联合协议是一种基于标准的方法，旨在尝试并为联合提供坚实的基础。您可以看到ATOM RFC这里 （链接到外部站点。） 尽管您不会全部实现！ 基于XML的格式易于通过Web的超文本传输​​协议（HTTP）进行传输，并且越来越常见的是使用标准格式在客户端和服务器之间进行交换，而不是针对一种小型协议开发特殊协议。客户端和服务器组。在20年前，我们可能已经在传输的数据中使用字节边界定义的模式进行通信了，而使用基于XML的标准和现有的HTTP机制来绕开事物则更为普遍。这是客户端和服务器之间基于套接字的通信，不需要使用Java RMI机制来支持它-正如您所期望的那样，因为您不必使用RMI客户端来访问网页！在本练习中，您将获取数据并将其转换为ATOM格式，然后将其发送到服务器。服务器将对其进行检查，然后将有限形式的数据分发给每个连接并请求该数据的客户端。当您要更改服务器中的数据时，您将覆盖现有文件，从而进行更新操作幂等（您可以随意进行多次，并获得相同的结果）。系统的真正测试是，您可以接受服务器上其他学生的PUT和GET请求，而客户可以与他们交谈。和往常一样，不要共享代码。 联合服务器 联合服务器是提供符合RSS或ATOM标准的XML文档的Web服务器。收到HTTP GET后，服务器将以如下XML响应进行响应（来自“在PHP中创建ATOM供稿” （链接到外部站点。））： 一旦配置好，服务器就会将该ATOM XML文件提供给通过HTTP请求它的任何客户端。通常，这将是Web客户端的一部分，但是在这种情况下，您将编写聚合服务器，内容服务器和读取客户端。内容服务器将在服务器上放置内容，而读取客户端将从服务器获取内容。 元素 该任务的主要内容是： • 一个ATOM服务器（或聚合服务器），用于响应对提要的请求，并且还接受来自客户端的提要更新。聚合服务器将永久存储提要信息，仅在提供提要的内容服务器不再联系或提要项不是最新的20之一时才将其删除。 • 客户端向服务器发出HTTP GET请求，然后显示提要数据（已删除其XML信息）的客户端。 • 一个内容服务器，向服务器发出HTTP PUT请求，然后将提要的新版本上载到服务器，以替换旧版本。从内容服务器的本地文件系统上的文件读取此提要信息后，该提要信息将被组合为ATOM XML。 所有代码元素都将使用Java编程语言编写。期望您的客户具有彻底的故障处理机制，使他们在遇到故障时可以预期地表现，保持一致性，不容易出现竞争状况并可靠且可预测地恢复。   此实践摘要 在此分配中，您将构建下面描述的聚合系统，包括一个故障管理系统，用于处理您可能会想到的针对此问题的尽可能多的故障模式。这显然包括客户端，服务器和网络故障，但是现在您必须处理以下附加约束（在阅读下面的描述后，请回到这些约束）： • 多个客户端可能会尝试同时进行GET，并且如果与任何PUT交错，则需要GET对Lamport时钟调整时间正确的聚合提要。因此，如果按此顺序到达一个PUT，一个GET和另一个PUT，则必须应用第一个PUT并建议内容服务器，然后GET将更新的提要返回给客户端，然后应用下一个PUT。在每种情况下，如果参与者使用Lamport时钟，将保证他们维持该顺序。 • 多个内容服务器可能会尝试同时进行PUT。必须将其序列化，并由Lamport时钟时间戳记维护顺序。 • 您的聚合服务器将过期，并从最近12秒钟内未通信的内容服务器中删除任何内容。您可以为此选择机制，但必须考虑效率和规模。 • 您的作业中的所有元素都必须能够实现Lamport时钟，以实现同步和协调目的。   您的聚合服务器 为简单起见，我们假设您的文件系统中有一个文件，其中包含条目列表以及它们来自何处。它不必是ATOM格式，但是当客户端发送GET请求时，它必须能够转换为标准ATOM文件。但是，此文件必须在服务器崩溃并重新启动后仍然可以承受，包括在服务器崩溃时是否正在更新文件时进行恢复！您的服务器应将其还原为重新启动或崩溃之前的状态。因此，您应该将PUT视为处理传递进来的信息（可能转换为中间存储格式）的请求，而不仅仅是覆盖文件。这反映了PUT的微妙本质-不仅仅是文件写入请求！您应该检查从PUT请求提供的提要文件，以确保它是有效的。 系统中的所有实体都必须能够维护Lamport时钟。 首次创建ATOM Feed时，您应该返回状态201-HTTP_CREATED。如果以后可以上传，则应该返回状态200。（这意味着，如果内容服务器首先连接到Aggregtion服务器，则返回201作为成功代码，然后在内容服务器断开连接之前，所有其他成功响应都应使用200）。 。除GET或PUT之外的任何其他请求都应返回状态400（注意：这不是标准操作，只是为了简化您的任务）。不向服务器发送任何内容应导致返回204状态码。最后，如果ATOM XML没有意义，则可能返回状态码500-内部服务器错误。 默认情况下，您的服务器将在端口4567上启动，但将接受一个给出起始端口号的命令行参数。您服务器的main方法将驻留在名为的文件中AggregationServer.java。 您的服务器旨在保持最新状态，并将删除Feed中来自内容服务器的所有项目，这些内容在12秒钟内未与之通信。如何执行此操作取决于您，但请高效！ 您的GET客户 您的GET客户端将启动，阅读命令行以查找服务器名称和端口号（以URL格式），并将发送对ATOM提要的GET请求。然后，将剥离该提要的XML，并一次显示一行及其属性及其值。GET客户端的main方法将驻留在名为的文件中GETClient.java。服务器名称和端口号的可能格式包括“ http：//servername.domain.domain：portnumber”，“ http：// servername：portnumber”（具有隐式域信息）和“ servername：portnumber”（具有隐式域和协议信息）。 您应该显示输出，以便于阅读，但您无需提供活动的超链接。您还应该使该客户端具有容错功能，并且显然，您必须使客户端能够维护Lamport时钟。 您的内容服务器 您的内容服务器将启动，从命令行读取两个参数，其中第一个是服务器名称和端口号（对于GET），第二个是文件在Content