note
BrowserUk
<blockquote><i>I use IO::Socket::UNIX for both the client and server.</i></blockquote>
<p>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.
<P>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);
<P>On windows, named pipes also work with the local server domain and are substantially faster than (INET) sockets.
<blockquote><i>I typed this code in, so I doubt it will compile ...</i></blockquote>
<p>Unfortunately, that means it doesn't tell us anything useful.
<p>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.
<blockquote><i>Here are some results: ...</i></blockquote>
<p>I assume, though you haven't stated it, that your concern is the lower throughput rate for inter-process comms versus intra-process comms.
<P>I afraid that is to be expected.
<P>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.
<P>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.
<p>In short:inter-process comms will always carry substantially greater overheads that intra-process (inter-thread) comms. That is inevitable.
<blockquote><i>So, if I could keep a persistent connection between the server and the client then performance may be better. </i></blockquote>
<p>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 <i>transient connections</i>?
<p>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.
<p>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.
<P>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?
<div class="pmsig"><div class="pmsig-171588">
<hr />
<font size=1 >
<div>With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'</div>
<div>Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.</div>
<div>"Science is about questioning the status quo. Questioning authority". </div>
<div>In the absence of evidence, opinion is indistinguishable from prejudice.
<p align=right>[http://www.theregister.co.uk/2011/11/29/sas_versus_world_programming/|The start of some sanity?]</p></div>
</font>
</div></div>
968334
968453