in reply to Re^3: Single server-multiple clients
in thread Single server-multiple clients

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?

Replies are listed 'Best First'.
Re^5: Single server-multiple clients
by Corion (Patriarch) on Jul 20, 2010 at 19:32 UTC

    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.

      Apologise for the slang

      fixed parts so far:

      1. Server and 2 Clients are made through socket program. ( The Code is something which I took from the net).

      2. To write/read files to/from disk/client ( using simple file operations).

      3. Verifying the MD5 of an x-client. ( By first,regex-ing the path of client and the drive, then perform verification(if md5_hex(path1/clientx/filex) Eq (md5_hex(pathx/diskx/filex)).

      parts to be fixed:

      1. How to make clients wait at the server, so that server can update their status on its table.
      2.If I use request/respond type... Will the proxy server be a function ( sub proxy()) or should it be connected to the server through sockets again.

      for clarification: The clients are on different machine.
      wherever I type
      %/> perl client.pl
      the client pings the server, when I type the same line on another machine( the same client-code I believe). Its the client2 that's pinging the server now.. so on..

      Thanks

        Have you considered making your protocol just HTTP?

        Also, have you considered that file I/O will be so slow that it will deliver data at the same speed whether one reading machine is reading from it or two? The two machines will each get (at best) half the speed.