client/server

[George Mpouras]

Let’s say I have n servers and each one should have a client and a
server component (in Perl) . The client connect to other servers,
process their answers and the server component serves these answers (to
the other servers clients) . What do you think is the best way to build it.

1) As one service that is both client & server (easier to have shared
variables between them)

2) Two completely separate scripts (client / server) , which will be
easier to write , but more problematic for the client to read server’s data

 

[Jürgen Exner]

Let’s say I have n servers and each one should have a client and a
server component (in Perl) . The client connect to other servers,
process their answers and the server component serves these answers (to
the other servers clients) . What do you think is the best way to build it.

1) As one service that is both client & server (easier to have shared
variables between them)

2) Two completely separate scripts (client / server) , which will be
easier to write , but more problematic for the client to read server’s data

That would depend to a very large degree on what kind of service you are
talking about, what kind and size of data you are expecting, how long
retrieving the data takes, if your server and the client on same machine
need to synchronize their actions or if your client can retrieve the
data asynchroniously and cache it locally, etc, etc, etc.

And none of these questions has anything to do with Perl.

jue

 

[Rainer Weikusat]

Let¡¯s say I have n servers and each one should have a client and a
server component (in Perl) . The client connect to other servers,
process their answers and the server component serves these answers
(to the other servers clients) . What do you think is the best way to
build it.

1) As one service that is both client & server (easier to have
shared variables between them)

2) Two completely separate scripts (client / server) , which will
be easier to write , but more problematic for the client to read
server¡¯s data

I would go for the second, having a documented interface for client <->
server interactions and possibly, an independent 'message constructing
and interpreting library' shared by both insofar they are/ were written
using the same language.