Client3 needs to verify client1 and client2. client 4 needs to verify all client1,2 and 3s..

How many clients are there?

Say there were 10. The tenth client has to check 9 md5s and produce one. But who'd check that one?

And why, if two clients have already checked the MD5 of a file and concurred, do you expect that a third client would suddenly produce a different result?

And, presumably the server can also access these files--else how does it randomly pick from them for the clients to operate upon? In which case, why not have the server pick a dozen of so files at random--calculate and store the MD5s--and then supply the entire list of files & md5s to each connecting client for verification. The only response required then is yes or no. Ie:

• Client connects:
• Server sends single packet of filename MD5 filename md5....
• Client reads list.
• Reads file and calculates md5.
• If different send "failed" to server; else sends "passed".
• Done.

clients are on different machines, how could the code fit in 20 lines

Well, that was for the server; the client would be about the same again. Eg.

Server:

#! perl -sw
use strict;
use threads;
use threads::shared;
use IO::Socket;
use Digest::MD5 qw[ md5_hex ];
use List::Util qw[ shuffle ];

use constant CRLF => chr( 13 ) . chr( 10 );
$/ = $\ = CRLF;

my %files :shared = map{
    open my $fh, '<:raw', $_ or warn "$_: $!";
    $_ => md5_hex( do{ local $/; <$fh> } );
} (shuffle glob '*.pl' )[ 0 .. 9 ];

my $server = IO::Socket::INET->new(
    LocalHost => 'localhost', LocalPort => 1234, Listen => SOMAXCONN, 
+Reuse =>1,
) or die "Couldn't create listening socket";

while( 1 ) {
    my $client = $server->accept;
    async {
        my $peerhost = $client->peerhost .':'. $client->peerport;
        print $client join ' ', %files;
        my $reply = <$client>;
        print $client 'DONE';
        warn "$peerhost : $reply\n";
    }->detach;
}

close $server;
__END__
c:\test>850473-s.pl
127.0.0.1:59137 : PASSED
127.0.0.1:59138 : PASSED
127.0.0.1:59139 : PASSED
127.0.0.1:59140 : PASSED
127.0.0.1:59141 : PASSED
127.0.0.1:59142 : PASSED
127.0.0.1:59143 : PASSED
127.0.0.1:59144 : PASSED
127.0.0.1:59145 : PASSED
127.0.0.1:59146 : PASSED
127.0.0.1:59147 : PASSED
127.0.0.1:59148 : PASSED
127.0.0.1:59149 : PASSED
127.0.0.1:59150 : PASSED
127.0.0.1:59151 : PASSED
[download]

Client:

#! perl -sw
use strict;
use Digest::MD5 qw[ md5_hex ];
use IO::Socket;

$/ = $\ = chr( 13 ) . chr( 10 );

my $server = IO::Socket::INET->new(
    'localhost:1234'
) or die $^E;

my %files= split ' ', <$server>;
my $result = 'PASSED';

for my $file ( keys %files ) {
    open my $fh, '<:raw', $file or warn "$_ : $!";
    my $md5 = md5_hex( do{ local $/; <$fh> } );
    warn "$file: $md5 eq $files{ $file }\n";
    next if $md5 eq $files{ $file };
    $result = 'FAILED';
    last;
}

printf $server "$result\cM\cJ";
print scalar <$server>;
close $server;

__END__
junk67.pl: c9c8f25e0d4263a253f45d63b18fb062 eq c9c8f25e0d4263a253f45d6
+3b18fb062
CPtest.pl: 103017b3f98578db15060a31316087e7 eq 103017b3f98578db15060a3
+1316087e7
junk2.pl: 5367ddba375163542c7197bfa355be88 eq 5367ddba375163542c7197bf
+a355be88
789655-2.pl: c6b1a7367b57bba6ae0e4556aeb1053c eq c6b1a7367b57bba6ae0e4
+556aeb1053c
burnCPU.pl: 0e8afcf32f03fa9382b1bce9b8a5646b eq 0e8afcf32f03fa9382b1bc
+e9b8a5646b
815861.pl: cb37349c218e9cd6d4017dc32e436d72 eq cb37349c218e9cd6d4017dc
+32e436d72
junk33.pl: c298090e1bc7f8ec599c3b9bff08598e eq c298090e1bc7f8ec599c3b9
+bff08598e
MovingAves.pl: 98f1b81b1d9ee099b937982320a1f347 eq 98f1b81b1d9ee099b93
+7982320a1f347
797136-b.pl: 02152b03bb0766e141da67739161f192 eq 02152b03bb0766e141da6
+7739161f192
junk67.pl: c9c8f25e0d4263a253f45d63b18fb062 eq c9c8f25e0d4263a253f45d6
+3b18fb062
817762verify.pl: f0a6b204112d7d8aa7df99e307890705 eq f0a6b204112d7d8aa
+7df99e307890705
CPtest.pl: 103017b3f98578db15060a31316087e7 eq 103017b3f98578db15060a3
+1316087e7
DONE
[download]

Browswer Uk thanks for your help. Very much appreciated.

there are 'n' clients.

The reason why every client is asked to verify is to confirm that the file in the CDS looks the same(seen) through all the clients.

the reason why I'm not sure if threading would be ideal is because, the client programs are on different machine, and their process are initiated sequentially( in the order of their pinging) so threading would make sense in that case? pl correct me if I'm wrong.

my idea was to make a peer-to-peer cleint architecture with same problem, so to start small I assumed a server which is not connected to the CDS and just supervises the clients

BrowseUK , is async coding possible with not using threads too?

Even if threads in Perl were like threads in C, how would that help you solve your problem?

You haven't told us what part of the protocol you want to implement, and what the protocol is supposed to achieve. I suggest you draw some ascii-art flow diagrams of the messages to be exchanged between server and client(s).

Also, for any consideration of implementation, tell us which parts are the slow parts. For example shared storage usually has bandwidth and/or latency problems.

From your description, I still see the "server" as one table in a database into which all clients write their MD5s of all files, but you seem to make it something more. Maybe if you tell us the goal, we can tell you a way to it.

if threading

Server code:

1) Setup the socket and keep listening at a particular port and update its table of client addresses. 2) when packet is received from client ( the data from client), u need to decode 2 things- a) address of the client ( who's sending it, only then u ll knw who else to send it to, for verification) and b) wat is the type of packet ( it cud be the current client sending its md5 or it cud be the other clients who r verifying the current client is right) 3) if its "a", then it shud refer to its table and send a request to all other clients to see if this info is right. if packet type is "b" then it has to keep track of how many clients ve confirmed the data sent by the current client.

Client code:

1) client will have 2 threads- one thread will keep sending its md5 to server. one thread will listen to the server-and it ll c if the server is sending requests askin it to verify if the md5 sent by sum other client is right..

struct { int type; int data; }packet;

I know a little of C -threading and drew this plan for PERL,

but I'm not sure If this would work, because, client has to send the packet to server through socket , but I believe structs cant be sent thro sockets.. how to implement the communication of information b/w client(s) and server,hence keeping them on the same page. ( the only communication I cud think of is, establishing the socket and confirming the connection at server n client end.)

.

The server n client simulation and the entire communication of info between them is what i'm trying to build.

shared storage- It is just another machine's directory, eg C:/User/Disk

If threading doesnt work the way I'm expecting it to, I'm clueless what would be suitable for this problem, because server should always be listening ( only then will it be able to not block 2 client while its still communicating with the first one),

makes sense?

What parts of this still very unstructured stuff are fixed and what parts are your idea of an implementation?

Things get much, much easier once you reduce your protocol to a request-response structure. For example, clients could always initiate the communication by a request, be it "Here is an MD5 for my own file" or "Is there a file I should compute an MD5 for?".

I really recommend first thinking through the flow of messages through your whole system instead of thinking about threads and structs. Alternatively, learn first about network programming. Or learn about multiprocessing. But not all three in the same project and not at once.

Also, I'm not a native speaker of the English language, which makes it hard for me when you use txtspk like "u cud" where I expect to read "you could". If you would take more time to proof-read and expand your writing, that would make it more pleasant for me to read it.