Bugzilla – Full Text Bug Listing
| Summary: | TCF Peer accessible via two networks appear as two distinct peers | ||
|---|---|---|---|
| Product: | [Tools] TCF | Reporter: | John Cortell <john.cortell> |
| Component: | Core | Assignee: | Project Inbox <dsdp.tm.tcf-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, eugene |
| Version: | unspecified | ||
| Target Milestone: | 0.4.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
John Cortell
> A solution would be to introduce a core peer attribute that will uniquely
> identify a running agent instance on a host.
Actually, an agent ID would help, but it would be a lot easier for the observing agent if the peer also had an attribute that uniquely identified the peer instance *within* the agent. Something as simple as an index, e.g., would suffice. Thus, identifying a single peer would merely be a matter of comparing the agent ID and the peer-instance ID.
(In reply to comment #1) > Actually, an agent ID would help, but it would be a lot easier for the > observing agent if the peer also had an attribute that uniquely identified the > peer instance *within* the agent. Something as simple as an index, e.g., would > suffice. Thus, identifying a single peer would merely be a matter of comparing > the agent ID and the peer-instance ID. I'm not sure I understand this part. Peer already has a unique ID. This ID uniquely identifies the peer instance both within and outside the agent. How the second peer ID can help? (In reply to comment #2) > (In reply to comment #1) > > Actually, an agent ID would help, but it would be a lot easier for the > > observing agent if the peer also had an attribute that uniquely identified the > > peer instance *within* the agent. Something as simple as an index, e.g., would > > suffice. Thus, identifying a single peer would merely be a matter of comparing > > the agent ID and the peer-instance ID. > > I'm not sure I understand this part. Peer already has a unique ID. This ID > uniquely identifies the peer instance both within and outside the agent. How > the second peer ID can help? The reference implementations give each of the peer-objects a different ID since it forms the ID as follows: IP-addresss:port-number. So the peer it notifies each subnet with has different IDs: PEER-ID 1: 198.168.154.24:1534 PEER-ID 2: 10.23.155.23:1534 PEER-ID 3: 127.0.0.1:1534 All three peer objects represent a single peer running in a single agent. (above is a peer with two NICs and of course the loopback address) (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Actually, an agent ID would help, but it would be a lot easier for the > > > observing agent if the peer also had an attribute that uniquely identified the > > > peer instance *within* the agent. Something as simple as an index, e.g., would > > > suffice. Thus, identifying a single peer would merely be a matter of comparing > > > the agent ID and the peer-instance ID. > > > > I'm not sure I understand this part. Peer already has a unique ID. This ID > > uniquely identifies the peer instance both within and outside the agent. How > > the second peer ID can help? > > The reference implementations give each of the peer-objects a different ID > since it forms the ID as follows: IP-addresss:port-number. So the peer it > notifies each subnet with has different IDs: > > PEER-ID 1: 198.168.154.24:1534 > PEER-ID 2: 10.23.155.23:1534 > PEER-ID 3: 127.0.0.1:1534 > > All three peer objects represent a single peer running in a single agent. > > (above is a peer with two NICs and of course the loopback address) In this example we have 4 entities: 1 agent and 3 peers. Each peer is essentially a socket address. The agent is a service provider. The agent owns all 3 peers - one to many mapping exists between agents and peers. Locator service is like address book: it contains list of addresses - aka peers. But, unlike real address book, it does not say who owns an address, which makes it less useful. We can fix it adding agent ID in each entry. Do you agree? (In reply to comment #4) > In this example we have 4 entities: 1 agent and 3 peers. > Each peer is essentially a socket address. > The agent is a service provider. > The agent owns all 3 peers - one to many mapping exists between agents and > peers. > Locator service is like address book: it contains list of addresses - aka > peers. > But, unlike real address book, it does not say who owns an address, which makes > it less useful. > We can fix it adding agent ID in each entry. > Do you agree? I don't agree. I see things differently. I see five entities. We have 1 agent, 1 peer, and 3 of what I call "peer-objects" or access points to the peer instance. That is, the one peer makes itself available via three network interfaces, by basically making itself _look like_ three peers. That is entirely what this bug report is about. The fact that you have one peer out on the network basically representing itself as three so that it can make itself available across all the subnets its host machine is running on. _That_ duplication is what clients need to detect. The fact that there are two visible peers (in the original example) that are offering up the same exact services, and that are ultimately the same piece of code running on some host. The only difference between using one and the other will be network characteristics. The client program can then expose to the user the fact that he really only has ONE peer to choose from but TWO networks paths to it. (In reply to comment #5) > I don't agree. I see things differently. I see five entities. We have 1 agent, > 1 peer, and 3 of what I call "peer-objects" or access points to the peer > instance. That is, the one peer makes itself available via three network > interfaces, by basically making itself _look like_ three peers. That is > entirely what this bug report is about. The fact that you have one peer out on > the network basically representing itself as three so that it can make itself > available across all the subnets its host machine is running on. _That_ > duplication is what clients need to detect. The fact that there are two visible > peers (in the original example) that are offering up the same exact services, > and that are ultimately the same piece of code running on some host. The only > difference between using one and the other will be network characteristics. The > client program can then expose to the user the fact that he really only has ONE > peer to choose from but TWO networks paths to it. Now I see the source of confusion. We usually call "peer" what you call "peer-objects or access points". And we call "agent" what you call "a single peer". Apart from that, you comment is perfectly valid. > Now I see the source of confusion. We usually call "peer" what you call
> "peer-objects or access points". And we call "agent" what you call "a single
> peer". Apart from that, you comment is perfectly valid.
My notion of agent is based on how the term is used with respect to Discovery. A process (myagent.exe) exposing a set of services at port 9000 and another set of services at port 9010 is a single agent, not two. Agents are participants in discovery. Agents communicate with each other and advertise the peers they house. A process (myagent.exe) is a participant in discovery as a single agent for any given subnet, no matter how many ports it is exposing services only.
Correction. Last line should have read: A process (myagent.exe) is a participant in discovery as a single agent for any given subnet, no matter how many ports it is exposing services on. Fixed. On meeting with John and Felix we agreed that we need to identify 3 types of entities: 1. agent 2. service manager 3. peer A TCF agent houses one or more service managers. A service manager has a one or more services to expose to the world. The service manager creates one or more peers to represent itself, one for every access path the agent is reachable by. For example, in agents accessible via TCP/IP, the service manager would create a peer for every subnet it wants to participate in. In addition to peer ID, Locator service now supports two new peer properties: "ServiceManagerID" "AgentID" (In reply to comment #9) > Fixed. > > On meeting with John and Felix we agreed that we need to identify 3 types of > entities: > 1. agent > 2. service manager > 3. peer > > A TCF agent houses one or more service managers. A service manager has a one or > more services to expose to the world. The service manager creates one or more > peers to represent itself, one for every access path the agent is reachable by. > For example, in agents accessible via TCP/IP, the service manager would create > a peer for every subnet it wants to participate in. > > In addition to peer ID, Locator service now supports two new peer properties: > "ServiceManagerID" > "AgentID" Confirmed. Eugene, what can we say about expectations for these IDs? I imagine they are to be opaque (clients are not to attempt to decode/parse/interpret them). But what about uniqueness? I believe a PeerID is supposed to be universally unique (no two reachable peers must ever share the same peer ID). Is the same true for these new IDs? (In reply to comment #10) > Confirmed. Eugene, what can we say about expectations for these IDs? I imagine > they are to be opaque (clients are not to attempt to decode/parse/interpret > them). But what about uniqueness? I believe a PeerID is supposed to be > universally unique (no two reachable peers must ever share the same peer ID). > Is the same true for these new IDs? All 3 IDs are supposed to be opaque and universally unique. Implementation can use "reasonably unique" IDs like long random numbers, IP addresses or timestamps when standard UUIDs are not available or not feasible. Moving bugs to new home for IP log. Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3 |