如何通过网络在私人应用程序之间进行私人通信?
它基本上是一个安装在多台 PC 上的应用程序,每个安装都维护自己的数据库,该数据库与其他应用程序同步。 当它们同时启动(连接到同一网络)时。
我已经使用简单的套接字连接和自定义缓冲区对此进行了测试,但希望使应用程序之间的通信符合可接受的标准并且安全/稳健,而不是尝试重新发明轮子。
进行应用程序到应用程序通信的正常/标准方法是什么? 我在哪里可以找到更多信息?
另外,可以使用哪些技术来宣布和查找网络上的其他应用程序?
编辑: (完善我的问题)
下面 gimel 指出的 pub/sub 模型似乎符合我的需要。 然而,它涵盖了很多领域和内容。 我真的不知道该拿走什么& 使用所有这些。
看起来我还需要在两个或多个应用程序找到彼此后建立 P2P 连接 - 我该怎么做?
如果有可用的示例/教程,请指出。 实现我需要的东西的小型开源项目/模块也可以使用。
我选择的平台是 Linux,但基于 Windows 的示例也非常有用。
编辑[09-01-06]:
我目前正在考虑以下选项:
- 多播 (TLDP-Howto) - 这似乎可行,但我需要更多地研究它。
- 使用免费的动态 DNS 服务器,虽然这看起来有点冒险...
- 使用一些免费的电子邮件设施,例如 gmail/yahoo/...,并从那里发送/读取邮件以查找其他应用程序的 IP(可以工作,但感觉很脏)
- 已建议使用网络服务,但我不知道它们是如何工作的& 必须研究一下
,如果有任何例子,我将不胜感激您对这些选项的意见。 不幸的是,我无法选择使用中央服务器或网站(除非可以保证它是免费且永久的)。
[编辑2009-02-19]
(希望我能接受两个/三个答案!我接受的一个是因为它提供了思路和可能性,而其他答案则提供了固定但适用的解决方案。感谢所有回答的人,所有这些都有帮助。
) 当我找到/实现我的解决方案时,我将更新这个问题,如果解决方案足够,我将为其创建一个 sourceforge 项目。 (无论如何,这只是一个大得多的项目中的一个小问题。)
It's basically one app that is installed on multiple PC's, each install maintaining it's own database which is sync'd with other's as & when they are up (connected to the same network) at the same time.
I've tested this using simple socket connections and custom buffers, but want to make the comms between the apps conform to accepted standards and also to be secure/robust, and not try to re-invent the wheel.
What is the normal/standard way of doing this app-to-app comms & where do I find out more?
Also, what techniques are/can be used to announce and find the other apps on a network?
edit:
(refining my problem)
The pub/sub model pointed to by gimel below seems to be along the lines of what I need. It however covers a lot of ground & I don't really know what to take away & use from all that.
It also looks like I need to establish a P2P connection once two or more apps found each other - how do I do that?
If there are examples/tutorials available, please point them out. Small open source projects/modules that implements something like what I need would also serve.
My platform of choice is Linux, but Windows-based examples would also be very usable.
edit [09-01-06]:
I am currently looking at the following options:
- multicasting (TLDP-Howto) - this seems workable, but I need to study it some more.
- using free dynamic DNS servers, although this seems a bit dicey...
- using some free email facility, e.g. gmail/yahoo/..., and send/read mail from there to find other app's IP's (can work, but feels dirty)
- webservices has been suggested, but I don't know how they work & will have to study it up
I would appreciate your opinion on these options and if there are any examples out there. I unfortunately do NOT have the option of using a central server or website (unless it can be guaranteed to be free and permanent).
[Edit 2009-02-19]
(Wish I could accept two/three answers! The one I've accepted because it provides lines of thought and possibilities, while others came with fixed, but applicable, solutions. Thanks to all who answered, all of it helps.)
As & when I find/implement my solution, I will update this question, and should the solution be adequate I'll create a sourceforge project for it. (It is in any case a small problem within a far larger project.)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(12)
请参阅发布/订阅异步消息传递范例。
一个示例实现是 Apache ActiveMQ:
See Publish / Subscribe asynchronous messaging paradigm.
An example implementaion is Apache ActiveMQ:
嗯,
这有点像数学问题。 两台计算机找到对方后如何建立连接的问题相当简单。 您可以使用任意数量的 P2P 或客户端-服务器协议。 SSL 几乎普遍可用,但您也可以提供 SSL。 openssh.com/" rel="nofollow noreferrer">SSH,运行 Freenet 或其他。 一旦通过这些协议之一建立连接,用于交换数据的发布/订阅模型就可以很好地工作。 但
计算机如何找到彼此的问题是事情变得棘手的地方。 基本上有三种情况:
您的所有计算机都将位于您自己的局域网中。
在这种情况下,任何联机的计算机都可以广播其联机的消息,并获取有关其他计算机联机的消息。 请记住,任何广播/多播消息都必须发送到网络上的每台计算机,因为它不知道其目标是什么。 您无法在互联网上执行此操作,因为您无法向网络上的每台计算机发送消息。
您的计算机位于互联网上的任意节点上 ** 和 ** 始终至少有一台计算机连接到网络 ** 和 > ** 所有机器定期上线。
在这种情况下,每台机器都可以保留一个运行的 IP 地址列表。 当一台离线了一段时间的机器重新上线时,它会检查已知地址,连接到第一个有效地址 - 这就是 emule 协议查找服务器的方式。
您的计算机位于互联网上的任意节点上 ** 和 ** 所有计算机一起离线 ** 或 **相当多的计算机长时间离线其他人切换 IP 地址的时期。
在这里,我不认为您可以证明,如果没有一些中央服务器链接到公共 IP,新机器就无法找到彼此。 由于消息很大,因此无法在整个互联网上广播消息。 在这些情况下,计算机没有其他联机计算机的识别信息,因此您需要使用中央公共资源:您提到的电子邮件地址、网站、FTP 服务器、IRC 频道。 动态 DNS 只是集中式信息存储的又一实例。 如果您必须使用这样的商店,自然您必须评估所有可用商店的可靠性、速度和持久性。 除非您提供有关您的应用程序在这方面需要什么的更多信息,否则我认为其他人无法决定您需要哪个永久存储。
我认为这涵盖了所有的可能性。 您要做的就是确定您的应用程序属于这些一般情况中的哪一种,然后决定适合这种情况的协议之一。
编辑:
从反馈来看,情况 3 似乎适用。 从上面的推理来看,应该清楚的是,没有办法避免某种形式的外部服务器——大海捞针的唯一方法就是跟踪它的位置。 人们希望这样的提供商具备以下品质:
如前所述,有许多容易获得的资源或多或少符合此要求。 电子邮件服务器(如您当前使用的)、Web 服务器、FTP 服务器、DNS 服务器、IRC 频道、Twitter 帐户、网络论坛...
应用程序在一段时间后启动并需要在没有中央服务器的情况下进行更新的问题是这是一个常见问题,但主要在病毒编写者中常见 - 几乎任何拥有创建分布式应用程序的资源的组织也拥有维护中央服务器的资源。 也就是说,多年来的标准解决方案包括电子邮件、http 服务器、ftp 服务器、IRC 频道和动态 DNS 服务器。 每个类别中的不同服务器的速度、可靠性和持久性各不相同,因此选择一台服务器的任务取决于您的判断。 IRC 频道值得一提,因为它们快速且易于设置,但随着互联网的发展,这些频道确实可能会消失。
作为使用各种“客户查找”技术的分发应用程序的示例,您可以下载 源代码BO2K,一个,呃“远程管理实用程序”。 这可能会让您深入了解远程更新客户端的所有功能。
只是重复一下。 我想你的问题分为三个部分:
对于更复杂的情况,确实有一整套协议,但它们不同的复杂性将使它们难以用于简单的数据交换。 git scm 发送数据的方式是更新协议的一个示例。 如果碰巧你的数据库类似于 git 发送的源代码,你可以使用 git 来维护你的数据库。 但您的更新方法很可能与 git 的做法不太相似。 另一个示例协议是 Web 服务的一个或另一个版本,例如 SOAP。 这些协议只是包装使用 xml 和 http 在一台机器上调用函数的过程。 如果您已经可以在应用程序之间建立套接字通信,那么就没有理由这样做。 请记住,要实现 Web 服务,您需要运行一个 http 服务器并将 http 客户端的 xml 解析为原始数据。 考虑到您可以直接通过套接字发送数据,因此没有理由这样做。 所以你又开始自己动手了。
无论如何,一个简单协议的示例可能是:
它具有作为索引数组的数据。
然后应用程序会改变角色并以其他方式交换数据。 协议中给定的“握手”在伪代码中看起来像这样:
使用另一个函数来实现这些数据交换的另一端。
进一步考虑的是,如果数据库中的每个条目都是独立生成的,则您将需要生成一个唯一的 ID,而无法引用分布式数据库中的所有条目。 为此,您可以生成一个 GUID 或一个大的随机数。
如果您要使用它,毫无疑问您必须进一步调整和开发它。
但请记住,如果您的应用程序只是偶尔更新,则无法确定任何给定实例是否具有任何数据项。 例如,假设一天中有一半机器仅在下午 5:00 之后上线,另一半机器仅在下午 5:00 之前上线。 在这种情况下,如果两组机器直接互相更新,则不会共享任何数据。 另一方面,如果您的机器确实在均匀分布的时间上运行(而不是按照我描述的模式),那么每台机器最终很可能会获得所有更新(至少是所有旧更新) 。
鉴于这一切,我认为您应该准确考虑应用程序连接的频率以及所有数据完全同步的重要性。 在极不频繁的情况下,您可能需要使用外部服务器来移动数据以及寻找客户。 常规电子邮件是解决此问题的自然方法。 如果当另一台计算机在线时没有一台计算机在线,那么使用它是一回事。 如果您担心访问特定电子邮件帐户,您可以使用多个电子邮件地址列表启动每个应用程序,检查所有地址,并且您可以选择在给定地址失败时使用更多地址更新应用程序。 使用电子邮件处理所有事情的优点是简单。 您可以使用
更轻松的旁注,数字站是互联网出现之前的一项努力,旨在解决信息更新问题,但它们也不适合您的情况(但是,它们确实向世界大部分地区广播)。
Hmm,
This is a bit like a math problem. The question of how two computers establish a connection once they find each other is fairly straightforward. You can use any number of P2P or client-server protocols. SSL is almost universally available but you could also serve SSH, run Freenet or whatever. Once you establish a connection through one of these protocols, a publish/Subscribe model for exchanging data could work well. But there is
The question of how the computers FIND each other is where things get tricky. There are essentially three cases:
All your computers will be on your own local area network.
In this case, any computer that goes online can broadcast a message that it is online and get message back concerning what other machines are online. Remember any broadcast/multicast message has to every machine on the network since it doesn't know what its target. You cannot do this on the internet since you cannot send a message to every machine on the net.
Your computers are on arbitrary nodes on the internet ** and ** there will always be at least one of your computers connected to the web ** and ** all machine go online on a regular basis.
In this case, each machine can keep a running list of IP addresses. When a machine that's been offline for a while comes back online, it checks for the known addresses, connecting to the first valid address - this is how the emule protocol finds servers.
Your computers are on arbitrary nodes on the internet ** and ** all machines offline together ** or **quite a few go offline for long periods while otheers switch IP addresses.
Here, I don't think that you can demonstrate that there is no way for new machines coming on to find each other without some central server to links to common IPs. There is no way to broadcast a message throughout the Internet because it is big. In these circumstances, computers have no identifying information for the other machines coming online so you need to use a central, common resource: the email address you mentioned, a website, an ftp server, an IRC channel. A dynamic DNS is just one more instance of a centralized information store. If you must use such a store, naturally you have to evaluate all the stores available for their reliability, speed and permanence. Unless you give more information about what your application needs in this regard, I don't think anyone else can decide which permanent store you need.
I think this covers all the possibilities. What you have to do is decide which of these general cases your application falls under and then decide on one of protocols which fits this case.
Edit:
From feedback, it seems case 3 applies. From the reasoning you can see above, it should be clear that there is no way to avoid some form of external server - the only way to find a needle in a haystack is by keeping track of where it is. The qualities one would want in such a provider are:
As mentioned, there are many easily available resources that more or less fit this bill. Email servers (as you are presently using), web servers, FTP servers, DNS servers, IRC channels, Twitter accounts, web forums....
The problem of applications that come to life after a while and require updating without a central server is a common problem but it common mostly among virus writer - just about any organization which has the resources to create a distributed application also has resources to maintain a central server. That said, standard solutions over the years included email, http servers, ftp servers, IRC channels and dynamic DNS servers. Different servers in each of these categories vary in their speed, reliability and permanence so the task of choosing one goes back to your judgment. IRC channels deserve mention because they fast and easy to set up but these might indeed fade as the internet evolves.
As an example of distribution application which uses a variety of "client finding" techniques, you can download the source to BO2K, a, uh "remote administration utility". This might provide some insight into all of the functionality of your remote updating client.
Just to repeat. I imagine there are three parts to your problem:
For more complex situations, there indeed a whole forest of protocols but their vary complexity would make them awkward to use for simple data exchange. The way that the git scm sends data is one example of a updating protocol. If it is just so happens that you database resembles the source code that git sends, you could use git to maintain your database. But the chances are your updating approach won't resemble what git does that closely. Another example protocol is one or another version of web services such as SOAP. These protocols just wrap the process of calling a function on one machine using xml and http. If you can already establish socket communication between your applications, then there's no reason to do this. Remember, to implement web services you'd need to run an run an http server and parse the xml that an http clients into raw data. Considering you can send your data directly through a socket, there's no reason to do this. So you are back to rolling your own.
Anyway, an example of a simple protocol might be:
data it has as an array of indexes.
Then the apps change roles and exchange data the other way. A given "handshake" in your protocol would look like this in pseudo code:
With another function to implement the opposite side of these data exchanges.
A further consideration is that if each entry in the database is being generated independently, you will need to generate an ID which is unique to this without being able to reference all of the items in the distributed database. You can generate a GUID or just a large random number for this purpose.
You will no doubt have to tweak and develop this further if you are going to use it.
Keep in mind, however, that if your applications are all only occasionally updating, there will no way of being certain that any given instances will have any data item. For example, suppose, in a day, half the machines only go online after 5:00pm and the other half only go online before 5:00 pm. In this case, the two groups of machines will share no data whatsoever if they directly updating each other. If, on the other hand, your machines really do on at even distributed times (rather than according to pattern like I described), it is reasonably likely that each machine will eventually get all of the updates (at least all of the old updates).
Given all this, I think you should consider exactly how infrequently your applications will be connecting and how important it is for all the data to be fully synchronized. In situations of extreme infrequency, you may need to use an external server to move your data as well as finding your clients. Regular email is natural solution to this problem. It would be one thing to use if no computer is ever online when another is online. If you are worried about access to a particular email accounts, you could start each app with a list of multiple email addresses, with all the addresses being checked and you having the option of updating the application with even more addresses as given addresses fail. Using email for everything would have the virtue of simplicity. You could use
On a lighter side note, numbers stations are a pre-Internet effort to solve the information updating problem but they also wouldn't fit your case (they do broadcast to a large portion of the world, however).
我几年前设计了一个与您所描述的类似的应用程序。 我设计了一个在每个桌面上运行的“广告服务器”,并使用 UDP 将其状态广播到网络上运行的任何其他程序。 现在,这有它自己的一系列问题,具体取决于您计划如何运行该应用程序...但是,这是它如何工作的快速而肮脏的...
我在端口上设置了一个“监听器”,这是一个选择通过对数据库服务器和应用程序连接到的数据库进行哈希处理。 这将确保我收到广播的任何人都使用与我相同的数据库,并允许应用程序的多个实例在桌面上运行(设计要求)。
然后,我设置了各种“BroadcastMessage()”函数来广播某些事件。 我什至允许开发人员使用我的 API 使用自定义负载数据创建自定义事件,然后让程序为该事件注册一个侦听器,该侦听器会在该事件进入时通知注册商,并将其传递随之而来的数据。
例如,当应用程序启动时,它会广播一条“我在这里”消息,任何收听该消息的人都可以吃掉该消息、忽略它或回复它。 在“我在这里”中,它包含正在运行的应用程序的 IP 地址,以便任何客户端都可以通过 TCP 连接连接到它,以获取必须传送的进一步数据更新。
我选择了 UDP,因为所有其他正在运行的实例都不需要看到这些广播。 这比任何事情都更方便......如果有人在您位于同一屏幕上时向数据库添加了一条记录,则新记录只会“出现”在您的桌面上。
它还派上了用场,如果管理员在运行应用程序时更改了用户的权限,则用户不必退出并重新进入应用程序,更新就会被接收并立即处理,并且用户可以执行以下操作:他们需要什么。
在只侦听这些类型的消息的线程上设置侦听器非常容易...如果您需要示例代码,我也可以提供,但它是用 C++ 编写的,并且是为 Windows 设计的,但它使用原始 wsock32 .lib,所以它应该很容易地转移到任何 Unix 平台。 (只需要 typedef DWORD,因为我经常使用它..)。
I designed a similar app to what you are describing several years ago. I designed an "Advertise Server" that ran on each desktop, and would use UDP to broadcast it's statuses to any other program running on the network. Now, this has it's own set of issues, depending on how you plan to run this application... But, here's the quick and dirty of how it worked...
I setup a 'listener' on a port, that was a picked by hashing the database server, and database the application was connected to. This would ensure that anyone I got a broadcast from, was using the same database as I was, and allowed multiple instances of the app to run on the desktop (A design requirement).
Then, I setup various "BroadcastMessage()" functions that would broadcast certain events. I even went as far as allowed developers using my API the ability to create custom events, with custom payload data, and then have the program register a listener, for that event, which would notify the registrar when that event came in, and pass it the data that came with it.
For example, when the app started, it would broadcast an "I'm here" message, and anyone listening could eat the message, ignore it or reply to it. In the "I'm here", it contained the IP address of the running application, so that any clients COULD connect to it via a TCP connection for further data updates, that HAD to be delivered.
I chose UDP, because it was not a REQUIREMENT that these broadcasts be seen by all the other running instances. It was more of a convenience than anything... If someone had added a record to the DB while you were on the same screen, the new record would just 'appear' on your desktop.
It also came in handy that if an admin changed permissions of a user while they were running the app, the user did not have to exit and re-enter the app, the update was received, and processed right there, and the user could do what they needed to.
It's really easy to setup a listener on a thread that just listens for these types of messages... If you need example code, I can provide that too, but it is in C++, and designed for Windows, but it uses the raw wsock32.lib, so it SHOULD transfer over to any Unix platform pretty easy. (Just need to typedef DWORD, as I used that a lot..).
我在网络管理中已经解决过几次这个问题。 您基本关心的问题似乎是“发现”,即您的应用程序如何相互发现。
老实说,最简单的方法是知道您的 IP 地址和 IP 地址。 一个掩码(大多数是 c 类),并尝试连接到该 c 类中的每台机器。
如果您默认为 C 类,则意味着它几乎始终适用于大多数网络。 然后,您可以允许覆盖,添加要连接的特定 IP 地址或其他子网。
要发现 C 类,您只需计算出您的 IP 地址(假设为 192.168.2.77),然后迭代 192.168.2.(1-254) 中的所有内容,尝试打开与每个地址的连接。
我已经用多个线程完成了(您可以通过这种方式一次 ping 所有设备,并在 3 秒内获得良好的结果。我在大约 5 分钟内发现了一个 B 类网络,有几百个线程!),或者您可以直接去在单个线程中从一个到下一个 - 但如果你这样做,请确保你的超时非常低(1/2 秒左右),否则它将永远花费 - 即使在 1/2 秒也将花费一分钟巡视。
您可能还想让发现线程以较低的速度在后台运行,始终寻找新的伙伴。
并缓存您的“已知良好”IP 地址以加快启动速度。
这不是一个困难的问题,但也不是微不足道的。 只是期望做一些跑腿工作。
此外,您可能希望能够添加新的 IP/掩码来扫描外部子网。 如果你想联系互联网上的设备,就没有办法解决这个问题(尽管一旦一台电脑发现了网络,如果你愿意,它可以将地址发送给所有其他电脑,而且这个地址可能会很快变得很大!)
I've solved this problem a few times being in network management. Your basic concern seems to be "Discovery", how do your apps discover each other.
Honestly the easiest way is to know your IP address & a mask (most are class c), and to try to connect to each machine in that class c.
If you default to class C, that means that it'll just about always work for most networks. You can then allow overrides where you add in either specific IP addresses to connect to, or additional subnets.
To discover a class C, you just figure out your IP address (let's say 192.168.2.77), then iterate over everything in 192.168.2.(1-254), trying to open a connection to each.
I've done it with multiple threads (you can ping all the devices at once that way and have good results within 3 seconds. I discovered a class B network in like 5 minutes with a few hundred threads!), or you can just go from one to the next in a single thread--but if you do that make sure your timeout is really low (1/2 a second or so) otherwise it will take forever--even at 1/2 second it will take a minute to make the rounds.
You probably also want to leave the discovery thread running in the background at a lower speed, always searching for new mates.
And cache your "Known good" IP addresses for quicker startup.
It's not a hard problem, but it's not trivial either. Just expect to do a little legwork.
Also, you probably want to be able to add a new IP/Mask to scan an external subnet. There is just no way around this if you want to contact devices on the internet (although once one PC discovers a net, it can send the address to all the others if you want, and that could grow really big really quick!)
您是否希望这是完全 P2P 的,或者您是否计划拥有一个中央服务器来执行除目录之外的其他操作?
为了通信安全,SSL应该没问题。 Java 以非常简单的方式支持这些(如果您正在使用的话)。 这是 SSL 的 参考爪哇6
Do you want this to be totally P2P or are you planning on having a central server for doing anything more then being a directory?
For communication security, SSL should be fine. Java supports these in a pretty straightforward way, if that's what you're using. here's the reference for SSL in java 6
好的。 正如所承诺的,这里是我从应用程序中提取的一些示例代码。 这预计不会编译和运行,这是我如何做到这一点的示例。 你可能必须做完全不同的事情。 另外,这是为 Windows 编写的,正如您将在代码中看到的,它使用 Windows 消息在服务器线程和主应用程序之间发送数据,但这一切都取决于您计划如何使用它。 我留下了一些比较有趣的部分供大家参考。
至于安全部分,我认为你可以处理该部分。 这只是在数据通过网络之前使用一些众所周知的密码对其进行加密的简单问题,所以我认为我不必包含任何内容。 例如,您可以看到我如何构造数据包标头,然后有一个通常由另一个结构组成的有效负载。 因此,加密该结构,将其作为数据发送,然后在另一端解密,并将其复制到正确的结构。
Ok. As promised, here is some of the sample code I ripped from my application. This isn't expected to compile and run, this is an example of how I did it. You may have to do yours completely different. Plus, this was written for Windows, and as you'll see in the code, it uses Windows Messages to send data across between the server thread and the main application, but that all depends on how YOU plan to use it. I left some of the more interesting parts in for you to reference.
As for the security part, well, I figure you can handle that part. That's just a simple matter of encrypting the data before it goes over the wire, using some well know cipher, so I didn't think I had to include any of that. For example, you can see how I constructed the packet headers, and then there is a payload that usually consists of another structure. So, encrypt that structure, send it as data, and then decrypt it on the other end, and copy it to the proper structure.
好的 - 所以 MQ 之类的东西听起来有点过头了。
我对您的应用程序的理解:
在同一网络上的多台计算机上运行的桌面应用程序 - 拥有自己的数据库,需要互相发现。
为什么不呢:
1)定期UDP广播/监听以“查找同一网络上的其他机器” - Java示例:http://java.sun.com/docs/books/tutorial/networking/datagrams/index.html
2)使用SSL套接字进行实际通信后发现:
http://stilius.net/java/java_ssl.php.. ..http://www.exampledepot.com/egs /javax.net.ssl/Client.html
Ok - so MQ and that type of thing sound like over-kill.
My understanding of your app:
Desktop app running on multiple machines on the same network - have their own databases, need to discover each other.
Why not:
1) UDP broadcast / listen on a regular basis to "find other machines on the same network" - example in Java: http://java.sun.com/docs/books/tutorial/networking/datagrams/index.html
2) Use SSL sockets for actual communication after discovery:
http://stilius.net/java/java_ssl.php....
http://www.exampledepot.com/egs/javax.net.ssl/Client.html
您是否考虑过使用 Bittorrent 类型的设置?
使用的通信原理应该为您构建应用程序提供相当坚实的基础。 您所需要的只是让两个节点相互了解,然后从那里开始构建。 我使用 MonoTorrent 来运行私有(100 个节点)数据网络,一个 RSS 提要来宣布需要哪些文件where(Wordpress 的修改版本)并在 SSH 隧道中执行所有操作。 我确实有一台管理网络的中央服务器,但它可以轻松地驻留在我的 100 个节点中的任何一个上。 使用动态 DNS 服务,如果我的服务器出现故障,第一个活动节点会设置自己的跟踪器作为备份。
您可以使用 XML 文件作为您的消息传递方案,或者修改 Bittorrent 网络的传输以将数据包直接传输到您的应用程序。 我认为你正在寻找的概念是在 Bittorrent 中。 第一个启动的节点将回收动态 DNS 条目(DynDNS 有一个相当易于使用的API)(如果网络上没有活动主机)。 (有一个缺点......当两个跟踪器在 TTL 窗口内启动时,我遇到了同步问题)
有很多参考 SSH 隧道 在那里,我只是因为有趣的图表而使用这个。 SSH 隧道并不是最有效的可用方法,但它是必须以编程方式将通信包装在 SSL 隧道中的一个非常好的替代方法。
我知道这些想法有点混乱,我只是希望它能为您指明正确的方向提供一点帮助。 PS...对于完全可移植的解决方案,您可以在 Java 或 .Net 中运行它(在 Mono 下运行。我什至有运行 Mono 的 AppleTV)。 那么操作系统甚至可以成为您操作的灵活部分。
Have you considered using a Bittorrent typed setup?
The communication principals used should give you a fairly solid base for building your application. All you need is for two nodes to know about each other and then it builds from there. I use MonoTorrent to run a private (100-node) data network, an RSS feed to announce what files need to be where (modified version of Wordpress) and doing everything in SSH tunnels. I do have a central server which manages the network, but that could easily live on any one of my 100 nodes. Using a dynamic DNS service, the first node alive sets up it's own tracker as a backup if my server goes down.
You can use XML files as your messaging scheme, or modify the transmission of the Bittorrent network to transmit data packets directly to your app. I think the concept of what you are looking for is in Bittorrent. The first node to fire up would reclaim the Dynamic DNS entry (DynDNS has a fairly easy to use API) if there wasn't an active host on the network. (There is a downside... I've run into sync issues when two trackers fire up within the TTL window)
There are quite a few references to SSH tunneling out there, I just use this one because of the fun diagrams. SSH tunneling isn't the most efficient method available but it is a very nice alternative to having to programatically wrap your communications in an SSL tunnel.
I know the thoughts are kind of jumbled, I just hope it gives you a little help in pointing yourself in the right direction. PS... for a fully portable solution you could run this in Java or .Net (running under Mono.. I have AppleTVs running Mono even). Then OS could even a flexible part of your operation.
听起来您需要分布式缓存或离线数据库功能 - 根据您的语言(java/c#/...),有多种选项可供您选择...
Sounds like you need a distributed cache or offline db functionality - depending on your language (java/c#/...) there are various options open to you...
Amazon 和 Microsoft 都拥有托管队列,您可以将其用作任意数量的连接、协作应用程序之间的集合点。
亚马逊是商业的,不是免费的。 Microsoft 的 目前免费,但不保证永远免费。
它完全解决了您面临的问题。 为连接的客户端提供发布/订阅模型。
Amazon and Microsoft both have hosted queues you can use as a rendezvous point between an arbitrary number of connected, cooperating applications.
Amazon's is commercial, not free. Microsoft's is currently free, but not guaranteed to be so, forever.
It solves exactly the problem you are facing. Provides a pub/sub model for connected clients.
我可能在这里错过了一些东西,但我没有看到你选择的编程语言。
在基于Windows的环境中,使用.Net框架,最好的选择是使用WCF,它允许您通过简单的配置来添加安全性/稳健性。
如果您想要一个基于 Windows 的计算机而不是面向 .Net 的解决方案,我会考虑使用 MSMQ,它是根据这些标准构建的通信框架。
I may have missed something here, but I failed to see your choice of a programming language.
In a windows-based environment, using .Net framework, the best choice would be to use WCF, which allows you to add security/robustness with a simple configuration.
If you want a solution with windows based computers which is not .Net oriented, I would look into using MSMQ, which is a communication framework built to these standards.
这里有一篇关于 P2P 与 WCF 的好文章
http://msdn.microsoft.com/en-us/magazine/cc188685。 .aspx.
它提供代码,但假设.Net3、Wcf、Vista 及更高版本
There is good article about P2P with WCF here
http://msdn.microsoft.com/en-us/magazine/cc188685.aspx.
It provides code but assumes .Net3, Wcf, Vista and above