I have a network server (normal tcp connection) which offers a service that
clients use.
However some of these clients are automated applications which has a very
short run time.

E.g. think of a compiler. It might not run for more then max. 1 second but
be spawned LOTS of times if you have lots of files to compile.

These clients does a network request to the server each time they start up.
It's not very important that they get up-to-date information from the server
but the speed is a critical factor. So I'm thinking it would be an idea if I
could create a proxy service which e.g. polls the server each minute and
then a client connects to this local proxy instead of the real network
server.
This would work under the assumption that local processes communicating is
faster then network requests.

Are there any techniques to do this? I need this to work under Win32, Linux
and Solaris. Considering the nature of this group, only assume Solaris and
Linux for now.

I don't know what options there are under Linux and Solaris but ideas of
technologies could be useful. Of course I could write everything from
scratch to make a server and a new client but it might take quite a bit of
time. Still I don't know how to do communication between two processes. One
of these processes will have to act like a daemon though to be able to
communicate with new clients who wants the information from the server.

Thanks in advance.

-- Henrik

[ Post a follow-up to this message ]

"Henrik Goldman" <henrik_goldman@mail.tele.dk> writes:

> I have a network server (normal tcp connection) which offers a service tha
t
> clients use.
> However some of these clients are automated applications which has a very
> short run time.
>
> E.g. think of a compiler. It might not run for more then max. 1 second but
> be spawned LOTS of times if you have lots of files to compile.
>
> These clients does a network request to the server each time they start up
.
> It's not very important that they get up-to-date information from the serv
er
> but the speed is a critical factor. So I'm thinking it would be an idea if
 I
> could create a proxy service which e.g. polls the server each minute and
> then a client connects to this local proxy instead of the real network
> server.
> This would work under the assumption that local processes communicating is
> faster then network requests.
>
> Are there any techniques to do this? I need this to work under Win32, Linu
x
> and Solaris. Considering the nature of this group, only assume Solaris and
> Linux for now.
>
> I don't know what options there are under Linux and Solaris but ideas of
> technologies could be useful. Of course I could write everything from
> scratch to make a server and a new client but it might take quite a bit of
> time. Still I don't know how to do communication between two processes. On
e
> of these processes will have to act like a daemon though to be able to
> communicate with new clients who wants the information from the server.


Assuming you have structured your software as follow:


+----------------------+
| server functions     |
+----------------------+
| server side protocol |
+----------------------+
|
|
|
(network)
|
|
|
+----------------------+
| client side protocol |
+----------------------+
| client code          |
+----------------------+


you can start by merely joining the client side protocol module with
the server side protocol module, to put a "transparent proxy" on the
local host:


+----------------------+
| server functions     |
+----------------------+
| server side protocol |
+----------------------+
|
|
|
(network)
|
|
|
+----------------------+
| client side protocol |
+----------------------+
| server side protocol |
+----------------------+
|
(lo0)
|
+----------------------+
| client side protocol |
+----------------------+
| client code          |
+----------------------+

This way, the user programs don't have to be modified to use the
proxy, they only need to use 127.0.0.1 instead of the address of the
server.


Next step, you insert the caching code and you're done:

+----------------------+
| server functions     |
+----------------------+
| server side protocol |
+----------------------+
|
|
|
(network)
|
|
|
+----------------------+
| client side protocol |
+----------------------+
|      data cache      |
+----------------------+
| server side protocol |
+----------------------+
|
(lo0)
|
+----------------------+
| client side protocol |
+----------------------+
| client code          |
+----------------------+



--
__Pascal Bourguignon__                     http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

[ Post a follow-up to this message ]

>
> Assuming you have structured your software as follow:
>
Yes your assumptions are correct.

>           |
> +----------------------+
> | client side protocol |
> +----------------------+
> |      data cache      |
> +----------------------+
> | server side protocol |
> +----------------------+
>          |
>        (lo0)


I actually like your idea. It's very simple. My own idea was very similar to
this but thats because I didn't tell all the details when I wrote the first
post:

One problem about the data which the server returns is that the client must
verify if it's correct. In order to do that it makes a calculation which is
fairly expensive.
If I would use the scenario that you describe I would only speed up the
network traffic but not the calculation that goes on at the client side.
This calculation is guarrantied to be the same every time so thats where the
caching comes in. In other words the client-proxy should download the needed
data from the server and do the calculation just once instead of per started
application.

How about this:
Lets say I would start my app (which would contain both proxy and usercode).
Then I would see if there is a lockfile on the machine and if not I would
fork() a proxy out of the same process which would hold the actual client
and perform the connection to server and the calculation.

If noone would connect this forked proxy within e.g. 2 minutes it would shut
down. The assumption is that there could be e.g. 20 requests within this
time under normal circumstances.

This way I would have a proxy which starts up with the application (meaning
no seperate applications and thus easier for user). Also if the proxy is not
used it goes out of scope.

The only question left is how two processes can communicate with each other.
I'd like to avoid sockets since it's fairly expensive (even on localhost).
There must be other ways for two processes to communicate, not?

How about this idea? At first sight it looks appealing if I could find out
how to communicate.

Thanks in advance.

-- Henrik

[ Post a follow-up to this message ]

"Henrik Goldman" <henrik_goldman@mail.tele.dk> wrote in message
news:dvc7ar$i6i$1@news.net.uni-c.dk...
> The only question left is how two processes can communicate with each
> other. I'd like to avoid sockets since it's fairly expensive (even on
> localhost). There must be other ways for two processes to communicate,
> not?

What sort of protocol is involved? Why do you say sockets are "fairly
expensive"?

Alex

[ Post a follow-up to this message ]

On same box , U can also use message queues or shared memory for the
processes to communicate with each other .

eyemole

[ Post a follow-up to this message ]

> What sort of protocol is involved? Why do you say sockets are "fairly
> expensive"?
>

There are various reasons why I dislike sockets. One of them beeing that it
takes a amount of work to do proper synchronization since e.g. recv() could
return less then the message size. Also the software is deployed at
computers which I have no control over. Therefore I don't want to publish a
service which could be portscanned and possibly abused.

I think I'll go for message queues. Does anyone know some information about
speed of message queues? E.g. how high cost do they have?

I found that all posix implementations since around 1993 should have
mqueue.h and have functions like mq_open and it's friends. Does anyone have
experience with these? E.g. is it possible to have a non-blocking message
queue? I.e. if no messages are recieved within x seconds then do some
processing?

Thanks in advance.

-- Henrik

[ Post a follow-up to this message ]

"Henrik Goldman" <henrik_goldman@mail.tele.dk> wrote in message
news:dvhbe2$j7q$1@news.net.uni-c.dk... 
>
> There are various reasons why I dislike sockets. One of them beeing that
> it takes a amount of work to do proper synchronization since e.g. recv()
> could return less then the message size.

Only for stream sockets. You say "it takes a amount of work" - I'm not sure
whether you mean coding or processing, but neither are usually significant
in my experience. ("Partial" recv() calls can happen, but usually don't if
messages are small, and are usually not a major performance factor if
messages are large.)

> Also the software is deployed at computers which I have no control over.
> Therefore I don't want to publish a service which could be portscanned
> and possibly abused.

You could allow the service to be bound to the loopback address or use Unix
domain sockets.

> I think I'll go for message queues. Does anyone know some information
> about speed of message queues? E.g. how high cost do they have?
>
> I found that all posix implementations since around 1993 should have
> mqueue.h and have functions like mq_open and it's friends.

I think support is not universal, and msgget/ctl/snd/rcv are more readily
available.

However, sockets seem likely to be a more natural fit for the problem (I am
guessing - since you didn't answer - that the protocol is request/response,
but message queues give unidirectional IPC) and sockets-based IPC can of
course be multiplexed with network I/O between the cache service and the
server. Using sockets also leaves open the option of having the cache
service running remote from the clients with minimal code changes. Finally,
you are presumably already familiar with sockets so there is nothing (or
less) to learn.

I don't know about performance, but I can't see any reasons for substantial
differences with the different IPC methods except that shared memory might
be optimal. For a shared memory scheme to be significantly better, it
probably needs to be implemented with care, and even then the gain is likely
to be small unless messages are large.

Alex

[ Post a follow-up to this message ]