http://qs1969.pair.com?node_id=968501


in reply to Re^2: How to maintain a persistent connection over sockets?
in thread How to maintain a persistent connection over sockets?

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?