Sign in to follow this  

P2P?

This topic is 4657 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a basic knowledge of winsock, and a moderate knowledge of Win32, and I was thinking of learning a bit about P2P, leading into what might become a P2P instant messenger. Could anyone reccomend any good articles? Also, I have a question -- how do P2P apps get an initial IP address? How can they figure out WHAT to connect to? Doesn't there HAVE to be a central server that, at the very least, get's a P2P user started with the IP's of some of his peers? Edit: I probably shouldn't be trying to do this with my level of knowledge, should I... [Edited by - Pirate33 on March 8, 2005 4:45:53 PM]

Share this post


Link to post
Share on other sites
For some of the less advanced P2P apps, indeed, a list of servers are needed first off, and then those servers have a list of files, and who has them. The servers then connect the two computers together. I think some of the more advanced apps actually search the network, and form a mesh of clients, essentially. I don't think they rely on any list. :)

Share this post


Link to post
Share on other sites
For an instant messenger program, you'll need a central server. Otherwise you'll have to ask the user for the IP address of the other person. Which would mean they'd probably have to use MSN or something to ask their friend what their IP is :P
MSN has a central server (actually lots of them). When you log in, it sends you a list of your contacts, and what state they're in (online, offline, busy, away, etc). When you start a conversation with someone, MSN connects the two users to a switchboard session, and they talk to each other through the switchboard. This way the two users don't have a direct connection to each other, so you don't need to worry about disclosing peoples IP addresses (although it's not such a big problem as you might think) and you don't need to worry about firewalls / NATs (since neither user has to accept a connection).

Share this post


Link to post
Share on other sites
Quote:
Original post by ryanmfw
Yeah, but then the man could track you down..

:p
That's true. Actually, a P2P messenger might not be too bad. If you can find a way of getting around the asking for an IP problem, and don't want huge networks of people (one status change needs to be sent through the whole network). I still wouldn't want to write one though [smile]

Share this post


Link to post
Share on other sites
If you don't want the man to track you down, set your P2P system up such that you have to route queries through at least three other nodes before getting to the destination. Something like FreeNet, perhaps. Although they seem to have significant performance problems in their design.

Share this post


Link to post
Share on other sites
Idea.

You go and you have "uer management servers". These basically hand out usernames, with basekeys.

For eg. username:NC@server.
basekey:Somemd5Hashhere.

Now, only you know both your username and your basekey, so when your loging on, you go and you send your username, and a hash of the basekey, with an iv (that you give them), which forms your hashkey.

This way any user can autherise any other user. As well as check authentisity (if you trust the servers. But thats a given. Only allow you to talk to people who are authed by serers you trust.)

Naturally this can be extended, with basekey1, basekey2, basekey3, for a range of different base keys. (each one with different iv's tho).

This way, you would have to attack many many different servers, in order to appear to be someone who your not. (becuse you'd have to hack them to make sure that they would auth you).

You can also use pkc and sign the keys.

From,
Nice ocder

Share this post


Link to post
Share on other sites
Also don't forget:

Query random ip adresses to see if they are actual comps.

Once you find one, he can then tell you a few comps that he is connected to. You can then check them to find which ones there connected to, ect. (you jsut grab a few ips to connect to, so you have, maybe 1K connections).

Form,
Nice coder

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by ryanmfw
Yeah, but then the man could track you down..

:p
That's true. Actually, a P2P messenger might not be too bad. If you can find a way of getting around the asking for an IP problem, and don't want huge networks of people (one status change needs to be sent through the whole network). I still wouldn't want to write one though [smile]


Eh, just ping everyone on the internet. You'll eventually find whomever you desire to speak with. :p

EDIT: Upon reading this, I didn't solve the first problem, and I just dodged the second one. I need sleep, ok! :P I'll post with a better reply later. :)


OK, in all seriousness, searching for other nodes by pinging nearby computers I think is already done by a lot of the newer P2P programs, and it works pretty well. That's certainly something that *could* be done, but, the scheme only works if you don't care about who you talk to. To find a certain node, you must first connect to a node, and then conduct a search of all of the nodes it's connected to. Only once you've done an exhaustive search of all of the nodes it's connected to, you can be sure it's not on that chain. Then you have to move to another node, seperate from the previous list, which you must then exhaustively search. With the millions of people using IM programs, it would become *incredibly* cumbersome. Nice Coder's idea of having a central server to hand out the IP's of friends could work though.

Essentially, just have a central server that maintains IP addresses with usernames. To add a friend to your friend list or just chat with them, you would ask the server to mediate between you and your friend. You would have already established a secure connection with the server. The server would contact the friend's client, which would inform the user that you would wish to chat, or add them to your friend list. If the client accepts, keys are exchanged securely between you, and the server sends the IP of the friend to you. For just a chat, that would be that, except, maybe a temporary key would be used, instead of the normal one, but for adding to a friend list, another bit of information should be stored by you, to verify to the server that you have previously chatted, and have been accepted by your friend to become a buddy. This, I think, was what Nice Coder was talking about, or at least, it's similar.

This is really off of the top of my head here, but this might work. Let's say someone contacts you to be a friend of theirs, well, if you accept, you take your private key, encrypt their username, or whatever, if you want, encrypt that as well, and then send that off to your new friend. Upon resuming of the chat, the server passes the token that your friend stored back to you, where your client verifies that the token is correct(i.e. matches the username, and is someone on your friend list as well), and tells the server to connect you directly. The advantages would be that it would be P2P. the conversations could(should) be encrypted, and, your IP address is only given to people you know.

I can't really think up anything more right now, but it's an interesting problem. I will be programming, however, a program to test how networks mesh, to see what the chances are of having to connect to different nodes.

Cheers,
Ryanmfw

Share this post


Link to post
Share on other sites
Quote:

Original post by ryanmfw
To find a certain node, you must first connect to a node, and then conduct a search of all of the nodes it's connected to. Only once you've done an exhaustive search of all of the nodes it's connected to, you can be sure it's not on that chain. Then you have to move to another node, seperate from the previous list, which you must then exhaustively search. With the millions of people using IM programs, it would become *incredibly* cumbersome.


If you're still desperate to make a p2p I think you could do this, but make it less cumbersome by keeping these connections open to the first few nodes you checked, up to a max of (some max number you think is appropriate) That way you know that even though "Bob" might only be talking to "John", he had to search 5 other node chains first so you can still get to those chains through him. This would create a much larger group and you could search further. However, it wouldn't necessarily be any faster if you're searching a more extensive node when they are still in another node.

Also, you could get connected nodes to also join a multicast group. Then to search the chain of people would only require one packet sent to the group.

Share this post


Link to post
Share on other sites
Well, that would help, but it would still be cumbersome. Here are the results from a quick python script I wrote:


For 100 trials run with 1000 nodes each with 5 connections, searched 100 levels deep:

Probability of being in a connection chain: 0.92215
Found 451 times in 99 trials
Average Level: 90.2527716186

Meaning, you have to search pretty deep on average to find anything. Of course, you could get lucky, but, still, I wouldn't want to rely on that.

I'm too tired to interpret the results I got anymore, I'll work some more on this later.

Cheers,
Ryanmfw

Share this post


Link to post
Share on other sites
Achtung! longish post. Tried to make it fun. Probably failed.-
Back on track: There are 2 main problems for a p2p IM protocol:
Conectivity
Searching

Both of these have already been solved (in a different context) by other people, among them the eMule team. Go to their site, read their tech docs. Their authentication system is pretty good (for its intended purpose, confirming identity). About searching, read about the Kad (Kademilia? Kademlia?) protocol.

But there's still the problem of conectivity with a small network, since Kad's strength seems to be in (big) numbers.
So, I suggest a gmail approach to it.
Something like this:
I hereby invite you to the p2p IM network. Here's a special download link that will serve you a copy of the IM along with my IP to connect with (or a list of them?). This will provide instant connectivity to any newcomers, and such links could be used to refresh the IP list later, etc.

Now we're connected, and I (Green) want to find my friend Red. The comms would be as follows, in a funny sort of network traffic =)
Me: *poke*
subject a: yes?
Me: Are you Red?
subject a: no
Me: Do you know him?
subject a: no, but let me ask around if anyone near does *goes and ask*
subject a: nope, on one does. (if yes, subject 'a' would point me to the proper IP.)
Me: k thx. Send me some IPs for connectivity.
subject a: k,u 2 *sends list*
Me: *sends list*

Me: *poke*
subject b: yes?
Me: Are you Red?
subject b: yes
Me: I am Green. Here's the token I sent you last time we met.
subject b: sorry, wrong Red
Me: k thx. Send me some more IPs
*lists are exchanged*

Me: *poke*
subject c: yes?
Me: Are you Red?
subject c: yes
Me: I am Green. Here's the token I sent you last time we met.
subject c: Yes, you're the Green I know.
Me: Okay then, show your stuff.
subject c: Here's the token I sent you last time we met.
Me: Liar. You're not the Red I know.
Me: Send me IPs
*lists are exchanged again*

Me: *poke*
subject c: yes?
Me: Are you Red?
subject c: yes
Me: I am Green. Here's the token I sent you last time we met.
subject c: Yes, you're the Green I know.
Me: Okay then, show your stuff.
subject c: Here's the token I sent you last time we met.
Me: Liar. You're not the Red I know.
Me: Send me IPs
*lists are exchanged again*

Me: *poke*
subject c: yes?
Me: Are you Red?
subject c: yes
Me: I am Green. Here's the token I sent you last time we met.
subject c: Yes, you're the Green I know.
Me: Okay then, show your stuff.
subject c: Here's the token I sent you last time we met.
Me: Yes, you're the Red I know.
Me: Send me IPs
*lists are exchanged again*
-----found!

Obtaining Status could be tricky, probably asked directly upon login, and clients would be responsible for sending an update if state changes. Dunno how this is usually handled.

Share this post


Link to post
Share on other sites
Ok, another suggestion:

First, start making up a connections list. Say 1000 people. (just randomly try to connect to all of them. You can do this quite quickly, if you have a seperate port which basically is an 'i'm here' connection sort of thing, that you only connect to. You then simply keep making up as many connections as posisble, then as they time out, you go and fined new ones. (i've seen a nice one, in vb, which maintains 2^16 active seaching connections, and as they timeout it goes and searches the next one. Really fast.).

Once, you have them, you send out a "Find persion" Packet.

That bounces from node to its children, to their children ect/ until it times out. (each one of these packets has an id. You store the id's for all packets that you've seen which shouldn't have expired yet. When you see a new packet, you then know wether you've seen it before).

So, if you've got a million subscribers, then it would take about 2 iterations to reach everyone (assuming no overlap. Try maybe 5 with.)

If you've got 1000000000000000000000000000000 subscribers (huge, actually), it would take 10 iterations to get there. (again assuming no overlap. More with overlap).

From,
Nice coder

Share this post


Link to post
Share on other sites
Quote:
Original post by Nice Coder
Ok, another suggestion:

First, start making up a connections list. Say 1000 people. (just randomly try to connect to all of them. You can do this quite quickly, if you have a seperate port which basically is an 'i'm here' connection sort of thing, that you only connect to. You then simply keep making up as many connections as posisble, then as they time out, you go and fined new ones. (i've seen a nice one, in vb, which maintains 2^16 active seaching connections, and as they timeout it goes and searches the next one. Really fast.).

Once, you have them, you send out a "Find persion" Packet.

That bounces from node to its children, to their children ect/ until it times out. (each one of these packets has an id. You store the id's for all packets that you've seen which shouldn't have expired yet. When you see a new packet, you then know wether you've seen it before).

So, if you've got a million subscribers, then it would take about 2 iterations to reach everyone (assuming no overlap. Try maybe 5 with.)

If you've got 1000000000000000000000000000000 subscribers (huge, actually), it would take 10 iterations to get there. (again assuming no overlap. More with overlap).

From,
Nice coder


That's assuming that it's a perfect tree, with no nodes interconnected among themselves between yourself and the person you're trying to find. The script I wrote, which simulates a completely random network, found it to be much higher then that. There mighta been a bug though. :P

And yeah, if I had the time, I'd look at the Shareaza source code. It's a quite good program. :)

Cheers,
Ryanmfw

Share this post


Link to post
Share on other sites

This topic is 4657 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this