分布式环境中的观察者

Question

Machine A needs to send a message to machine B. Machine A has a static IP but machine B does not.

One option I could think of to solve this problem is that machine B opens a TCP connection to machine A and then machine A sends the data/message to machine B. However, this solution has the following limitations:

a) It is not scalable if there are many such machines as machine B to whom/which the data has be sent. It might be a kill on the resources of machine A.

b) It is machine A that needs to send the data when it wants. Machine B does not know when there will be data for it. In the current design, machine B will have to keep polling machine A repeatedly with a TCP connection asking if it has any data for it or not. This can get expensive if there are many machine B's.

Is there a less expensive way to solve this problem? The Observer design pattern comes to mind. Machine B could subscribe to a notification from machine A to inform it when data becomes available. However, how does one implement the pattern in a distributed environment when machine B does not have a static IP?

Observer aside, is there a way other than using raw sockets for machine A to send that data to machine B, that would be less expensive?

Answer 1

What if machine B makes a call to machine A to register its IP address for updates? That would be a quick message exchange. Whenever machine A has data it could create a new connection to all of the IPs that have registered themselves and send them the data.

Answer 2

看一下IP多播 ，尽管您可以通过简单的UDP广播来解决。

Answer 3

Not having a static IP means that it is accessible from outside, but it's address changes?

If it does, then you can have the machine B call A.detach(old_ip); A.attach(new_ip) A.detach(old_ip); A.attach(new_ip) every time the address is changed.

Answer 4

I'd go with your original idea, except that there's no need to poll - B can just maintain an idle TCP connection to A at all times, then when A wants to send a message it just sends it out to all the clients it has connected at that time. Overhead won't be a problem - even a fairly old machine can handle thousands of simultaneous mostly-idle TCP connections.

(You'll also want to implement some kind of keep-alive echo / echo reply type messages if the gaps between real messages are longer than a few minutes, so that B can quickly detect a dead connection and reconnect, and to avoid connection-tracking information in firewalls or routers in path from timing-out).