Concise representation of a peer end-point for better visualisation.

[p2psp]

Concise representation of a peer end-point for better visualisation.

[vicente-gonzalez-ruiz]

Although at this moment the simulator only runs teams in a host, the idea is that it should be able to spawn teams in several hosts. So, the answer is: the endpoints can be any (always using IPv4, forget IPv6).

[sachinsngh165]

Is it possible that a peer can send chunk to another peer before sending 'hello' message to it ?

[vicente-gonzalez-ruiz]

Send, not. Receive, yes. Think about the [hello] is lost.

[cristobalmedinalopez]

What about a method where every peer is able to calculate the ID of the other peers based on their endpoints? Maybe something like a hash function.

[vicente-gonzalez-ruiz]

Yes, a hash function that is capable of translating the end-points of the peers to a positive integer of 7 bits, could work.

[sachinsngh165]

Can you please explain me what is the scope of this simulator. I Mean, do we want to run the simulator within a machine or between multiple machines (within the network or outside the network) ?
I'm asking this question because to make hash function we need to know address scope of end-points.

[sachinsngh165]

So for the moment should I only design the hash function for simulation within the host ? In this case, we just need to map port address to a number.

[cristobalmedinalopez]

Not really, we need to map (IP, port) to a number (or string?).

[sachinsngh165]

How about maintaining a shared memory to store dictionary ? Can we do that

[cristobalmedinalopez]

How about maintaining a shared memory to store dictionary ? Can we do that

Is it really needed? If we use the same "hash function" for all entities it is not necessary to share any information.
Note that I used "hash function" (between quotes) because I think that it could be something different. In our case is not mandatory to avoid (or difficulty) its reconstruction.

[vicente-gonzalez-ruiz]

I would like that the "hash function" to generate only a 7-bits output for any input (only to have a printable character). Obviously, this has limitations (only 128 peer/team will work without collisions), but this does not matter.

What about if the splitter, when a peer is joining the team, assigns to the incoming peer a different integer id Y and, these ids are sent with the list of peers? Thus, any peer will know the id of the rest of the peers of the team and when the buffers are printed, we only need to print Y mod 128, where Y is mapped by a dictionary indexed by the end-points of the peers.

[sachinsngh165]

I was thinking the same but what if a new peer arrive, then how would old peer knows about its id ( as old peer are no longer connected via splitter_socket ) then i was thinking we can send that id with [Hello] message but what if [Hello] message get lost.

On simple solution could be if splitter manage all the peer ids and whenever a peer encounter a new end-point it will get its id from splitter and that peer will add this entry to its own dictionary.

[sachinsngh165]

Beside, using Hash function would be best idea.

[vicente-gonzalez-ruiz]

[hello]'s solution (I mean, the incorporation of the ids to the [hello] messages) is OK. As I said, the peer id is only important for printing the evolution of the buffers and we can live with this drawback (the lost of [hello]s). Anyway, if needed, the id could be sent with the chunks, but I don't think so, right now.

[sachinsngh165]

A hash function could be made by defining a relation b/w 8 bits blocks of ip address (e.g. x.x.x.x ) and finally with port number as follows:

def hash(addr,port):
	blk = addr.split('.')
	bk = [int(x) for x in blk]
	sh = bk[0]^bk[1]^bk[2]
	sh = (sh + bk[3])%127
	sh = (sh + port%127)%127
	return sh

what do you think ?

[cristobalmedinalopez]

I'm not sure about the operation of that function. For example, what if we have these two endpoints (192.168.2.1, 12345) and (192.168.1.2, 12345)? I guess that the same ID is assigned to both of them.
Anyway, it's a good start.

[sachinsngh165]

Yes you are right. But it is very difficult to avoid collisions because we are mapping 2^32 (4,294,967,295) addresses into 2^7 (127) address space.

I think the example you given is very least likely to happen in a local network. Because in a local network only host id change while network id remain same.
e.g.

Even though i'm looking for a better solution. :)

[cristobalmedinalopez]

it is very difficult to avoid collisions

Yes, I agree.

Because in a local network only host id change while network id remain same

That is true, but the number of bit used by hosts will depend on the class of the network, in your example it is a Class C, so 8 bits are used for hosts. However if it is a Class B, you could use 16 bit for host instead of 8.

[vicente-gonzalez-ruiz]

Don't you like the idea of the id's assigned by the splitter? If the id's are natural numbers, allocated sequentially (0, 1, 2, ...), collisions will appear only when more than 128 peers are in the team. Moreover, these collisions could be also convenient in the case we want to determine the sender of a chunk.

[sachinsngh165]

Don't you like the idea of the id's assigned by the splitter?

I think Splitter method would give very consistent results, and we can also give them sequential names. So representation would be nice. :-)

[sachinsngh165]

I have made following improvements to hash function:

def f(x):
    return (x*x)%127

def g(x):
    return (x*x*x)%127

def hash(addr):
    blk = addr[0].split('.')
    bk = [int(x) for x in blk]
    sh = bk[0]^f(bk[1])
    sh = sh^g(bk[2])
    sh = (sh + f(bk[3]))%127
    sh = (sh + g(addr[1]))%127
    return chr(65+sh%26) + chr(48+int(sh/10)%10)

How is it ?

[vicente-gonzalez-ruiz]

Seems to be a good hash function.

[cristobalmedinalopez]

It looks good for me too 😄

[sachinsngh165]

Since we have only 128-32-1=95 printable character i was wondering how we would able to represent 128 peers ? 😄

[vicente-gonzalez-ruiz]

No, it is impossible. However, it does not matter because we usually debug the buffer filling with small teams.

[sachinsngh165]

Please review my PR request .

[cristobalmedinalopez]

fixed in #32