0

I am curious as to how software developers solved the problem of having clients in a distributed computing network working on a particular problem have answers verified. I

ll relate this to what I am doing. I am making a distributed client/server program which works to factor semiprimes using basic trial division. The server sends each client a trial interval to check and see if the answer is in that interval.

The problem though is that after my server sends out the computational request for that interval to the particular client it waits for a response represented by a 'f' for failed and 's' for success depending on if the client found the factor in that interval. But what is stopping a malcious user from writing a program which plays the protocol to simply send an 'f' directly after the server sends its request making the server think the client legitametly checked the interval when in fact it didnt and the answer could have been in that interval screwing over the entire process. In a world where malicious hacking exists you can't exactly trust all clients to be there to help and I am wondering how professionals combated this problem.

Edited by cam875: n/a

2
Contributors
2
Replies
3
Views
7 Years
Discussion Span
Last Post by cam875
0

There are several options, most of them make the protocol significantly more complex. The goal would be to verify the client and/or the response.

You could start each conversation with some kind of challenge and response. Where your code would know how to respond and a fake client would have to reverse engineer the correct response.

You could incorporate a form of challenge/response into the reply data. If the reply were to include say the timestamp of the request, the timestamp of the reply, the dataset analyzed, the reply and a 'checksum' or signature your server could use that data to verify that the reply matches an outstanding request and came from a 'proper' client.

For the type of problem you described, an alternative might be to send the request out multiple times (to different clients) and compare all of their responses. If you have one client repeatedly not matching the other clients, its probably a bad (fake) client.

I'm sure there are other ways as well, but those are the first that came to mind.

0

yeah I understand the whole thing with the challenge/response protocol but my problem is that couldn't , if reverse engineered well, that be replicated to cause hazardous results. Because the client could forge all of the responses needed to trick the server into thinking its legitimate. I mean they could technically just send the checksum or hash of a legitimate client so the server thinks that the client has not been modified. Also this is an extremely computationally difficult task and I don't want to have to send out a request more than once if not needed. Trying to minimize computation as much as possible. I imagine that MMO companies have much the same problem with verifying client's files for malcious manipulation but there solutions might not be applicable to this situation. Thanks in advance for future help and to the previous poster.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.