So is there a way to keep the client connection persistent and only 'close' when the client is finished?

In general, tcp connections are persistent. That is, they only disconnect when either the client or server explicitly choose to do so. However, there is usually an 'inactivity' timeout period, often set (for historical reasons) to 900 seconds, though that can be modified at either end of the connection.

If you have reason to believe that your client might not (naturally) use the connection frequently enough to prevent the inactivity timeout from kicking, then the usual thing to do is add a 'heartbeat' message to your protocol. This takes the form of a do-nothing message or exchange, that can be initiated from either the client or the server, at some regular period less than the prevailing timeout.

And if the connection is persistent, would that prevent other clients from connecting?

That depends upon the implementation of the server.

Well written servers -- whether selecting, pre-forking or threaded -- can easily maintain concurrent, persistent connections with many clients. Hundreds or even thousands of concurrent connections are possible for low-volume protocols, but it obviously depends upon the design and implementation of the server; the volume of traffic per client; the capacity of the server hardware; and the bandwidth of the servers network connections.

But that's all very general information. To get better answers to your questions you'll need to describe your application in more detail; and outline what problems you are either experiencing or are anticipate encountering.

BrowserUk,

I use IO::Socket::UNIX for both the client and server. The routines are almost exactly the same as the perl documentation: Note: I typed this code in, so I doubt it will compile and this is just part of a lot of other code.

Server:

 use IO::Socket::UNIX;
 use strict;
 my $server = new IO::Socket::UNIX -> new ( Local  => "$ROOT/envSocket
+",
                                            Type   => SOCK_STREAM,
                                            Reuse  => 1,
                                            Listen => 147 );
 [ ... error handling ... ]
 while ( 1 )
 {   my $client = $server => accept();
     if ( defined $client )
     {   eval
         {  while(<$client>)
            {   $Todo .= $_; chomp($Todo); }
          }
          if ( $@ ) { ... }
          if ( $Todo ) { ... process work ... }
          close $client;
      }
 }
[download]

Client:

 use IO::Socket::UNIX;
 use strict;
 my $server = new IO::Socket::UNIX -> new ( Peer   => "$ROOT/envSocket
+",
                                            Type   => SOCK_STREAM,
                                            Timeout => 10 );
 [ ... error handling ... ]
 print $server "$Todo\n";
 shutdown ( $server, 1 );
 while ( <$server> )
 {   $answer .= $_;
 }
 shutdown ( $server, 2 );
 close $server;
 ...

 }
[download]

Even if I mistyped the code, the actual code works as expected. But the process is a lot slower than I had expected. Here are some results:

50,000 records processed:  ( results are number/second )

                              1 process | client/server
                     Writes:      2,953 | 1,152
                     ReadNext:   35,138 | 2,870
                     ReadPrev:   34,236 | 2,616
[download]

So, if I could keep a persistent connection between the server and the client then performance may be better. Everything I have tried has just hung. Some information supplied by zentara has given me some new ideas.

Any help will be greatly appreciated.

Thank you

"Well done is better than well said." - Benjamin Franklin

I use IO::Socket::UNIX for both the client and server.

That means I am probably the wrong person to be advising you. I don't use Unix domain sockets -- my platform doesn't have them -- and I know very little about them.

One thought that crosses my mind that I'll say out loud without doing any further research: As far as I'm aware, unix domain sockets only work within the local box; as such they are not so different from named pipes (fifos);

On windows, named pipes also work with the local server domain and are substantially faster than (INET) sockets.

I typed this code in, so I doubt it will compile ...

Unfortunately, that means it doesn't tell us anything useful.

If you posted snippets of the real code, we might be able to spot implementation errors; even if they were not complete and runnable; but uncompilable random snippets tell us nothing.

Here are some results: ...

I assume, though you haven't stated it, that your concern is the lower throughput rate for inter-process comms versus intra-process comms.

I afraid that is to be expected.

The latter is probably implemented as a simple memory buffer within the single processes address space. As such the api's have no need to perform ring-3/ring-0/ring-3 (user space to kernel space) transitions.

The former will be built around a process-shared memory buffer and will involve those user/kernel space transitions for every api call. In addition, they will also require kernel level locks; and may well invoke waiting for multiple task-switches until the appropriate other process -- the client or server process that is the communications partner -- to get a kernel timeslice.

In short:inter-process comms will always carry substantially greater overheads that intra-process (inter-thread) comms. That is inevitable.

So, if I could keep a persistent connection between the server and the client then performance may be better.

There is nothing in the text of your description; nor the (possibly unrepresentative) code snippets you've posted that suggests you aren't already using "persistant connections". How/why do you reach the conclusion that you are using transient connections?

In essence, what I'm suggesting here is that you are wrongly attributing "slow comms" to "a lack of persistent connections", without providing any evidence for the latter.

I think this is one of those (relatively rare) occasions where the X/Y problem raises its head. That is, you are describing what you've wrongly concluded is the source of your problem and are asking how to fix that; rather than describing the actual symptoms that are telling you that you have a problem, and allowing us to access the possible causes.

From your previous posts and questions I have an idea of the project you are working on; and I know you are breaking new ground in many areas concurrently. Perhaps you need to step back a little and describe the actual requirements of this part of your project and ask a more general question of teh best approach to satisfying them?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

zentara,

That answers part of my problem!

Now I have a lot of new questions, so I'm going to do some research and use some sample scripts to see if I can get a better understanding of the process.

Thank you

"Well done is better than well said." - Benjamin Franklin

Start by perusing CPAN and looking at modules like Net::Server and its brethren.

Never re-invent a wheel.

How does this answer either of flexvault's questions?