Skip to main content

Should Pipe ID be unique for each peer?

3 replies [Last post]
Joined: 2006-01-26

Say, I have a private network and n number of peers are part of the nw. Can all peers need to have the same Pipe ID or do they need different one?

Scenario 1
P1 wants to send a file to P2 via JxtaSockets. P2 starts a JxtaServerSocket with pipe ID, say "abc", does P1 create a JxtaSocket with same pipe id "abc" or does it create its own pipe ID?

Scenario 2
Once the file tranfer is completed in scenario 1, the sockets are closed. Now after some time P2 wants to send a file to P1, then I am assuming that P1 should have created a JxtaServerSocket and P2 should create the JxtaSocket. Now, is the pipe ID same as before or can they be different?

Scenario 3
P1 also wants to receive files from other peers, say P3,P4... So
1. Does it create a JxtaServerSocket for each peer?
2. If yes, then does each JxtaServerSocket has a unique pipe ID, or is it the same?

How are these pipe ID's published? I could not find any examples of publishing and discovering pipe advertisements.

Any pointers will be appreciated.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10

When you open a pipe, there is a publishing on a RDV of the ID. This allows any peer opening the other side to locate you.

There is no reason to 'publish' and 'discover' a pipe advertisement. The only reason to do such a thing is if you are looking for the name or additional data of the pipe advert to constrain what pipe you were looking for. If you already know what pipe ID, like 'abc' simply opening both ends will cause the connection.

But suppose you have ten peers on id 'abc'. The RDV will simply connect you to the nearest peer. 'Near' is sort of a simplification. "Nearness' is a function of what RDV has a copy of the waiting ID.

Ok, next thing to understand. If everybody is waiting on 'abc', you can connect with a specific constructor that contains the peer ID of the peer with that pipe open. Be careful because we are talking about the specific peer ID in the same group as the pipe. You have a different peer ID in each group.

Last bit of warning. If everybody is waiting on 'abc', you can connect to yourself. This is a very nasty situation because it means your network can't be symmetrical with all peers offering the same service, at least with this method. I use other techniques, like dividing peers into groups where half are on 'abc' and the other is on 'xyz'.

Another method is a simple queue managed by a few peers that have the data to build a pipe ID for the next peer that can provide the service (sort of a round robin method). This could be done with peers or very efficiently via a web service.

Another method is a simple chord. This is similar to how the RDV works. Essentially there is a range that relates to an ID. Say we have 1 to 10, and through some method, you are assigned to be at 5. You can attempt to connect to any other peer except 5. If you can't find a peer, you can change your ID to 4 or 6, close 5 and try to connect to 5. This way you can balance the network. Not the best scenario, but it works.

Message was edited by: turbogeek

Joined: 2006-01-26

Thank you turbogeek. Appreciate your response.

Joined: 2008-06-18


In my app P1 creates a temporary socket advertisement with a random PipeID. P1 sends the socket advertisement in a message to P2's personal pipe and starts the socket (all the peers in my app have a personal pipe with the peerID as seed of the pipeID (method "newPipeID" with two arguments), the personal pipe is published every time a peer joins a group). Once P2 recieves the socket advertisement it connects to socket and begins the file transfer.