cman@IO.COM (Douglas Barnes) writes:
[dc nets stuff]
One head scratcher I've been considering is whether it would be better to simulate a token-passing scheme, or to have comparisons broadcast to all participants. [...]
Doug has already heard a lot of this over dinner discussions we have had on dc nets and networking, but here are a few more things I have been thinking about in regards to this. The idea we hashed around in the token passing realm was that members of the net would begin by knowing only thier partners (I will assume people are being honest in the network for the moment...) Each person will pass packets to the left, the person they share thier data with in the dc setup (i.e. the person whose menu they look behind and whose coin they compare thier toss with.) The "packets" will have two sizes, the small one for token negotiation and a large one for data transmission. Token-sized packets are passed until someone suceeds in transmitting the "i speak" token, then a data packet, and then token negotiation begins again. Everyone prepares two random numbers, one for the data sharing that is part of the dc net and another to use in the communications ring. When people have checked thier neighbors and are ready to transmit, they send thier second random number (and a random signed token so they know when they see thier token come back to them) to the person on thier left. When a packet is recieved, each number is incremented or not for the "same/different" message and passed to the next member. When your token finally gets back to you it is possible to check for the message sent by the net, you know your original random number and the number of passes necessary for you to get your token back tell you how many people are participating. Doug and I thought that perhaps if the broadcast signal was something like "1111(rand 8 bits)1111" and people backed down when they sensed collision, so that unless the 16 bits ended with 1111 people would know there was no token in that round (0 is the default message, when people colliding stop trying to send the negotiotion falls to zero for that round) and they would try again. Eventually someone would be able to transmit the sequence and because the number in the middle is random only they would know that they have the send token. Then people communicate for the preset length of the data packet and begin negotiating for the token again. As far as breaking up and reforming the network I am still looking for ideas, but have been reading some old crypto proceedings and I am going to play around with some ideas and see if Chaum's blind signature stuff coupled with a ZNP for proving identity might work (it happens to be the article I was reading on the way over to work and it has gotten me thinking...)
Also, I have thought of some ways of dealing with "slacker" processes or folks who suddenly drop out that work better with a broadcast approach, but there's probably a way to deal with them in the token-based scheme.
Yes and no. The internet is not a connection-oriented medium and it is impossible to know whether or not a particular packet made it through. "Broadcasting" is also tricky for the same reason. The designers of the net have worked out several schemes for getting around these problems, it makes no sense not to lift a few good ideas for this... jim