Re: IPC looking for simple/best way to communicate
From: Jim Gibson (jgibson_at_mail.arc.nasa.gov)
Date: 01/10/05
- Next message: Anno Siegel: "Re: eliminating empty elements of a list"
- Previous message: Jim Gibson: "Re: eliminating empty elements of a list"
- In reply to: whansen_at_corporate-image_dot_com_at_us.com: "Re: IPC looking for simple/best way to communicate"
- Next in thread: xhoster_at_gmail.com: "Re: IPC looking for simple/best way to communicate"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 Jan 2005 14:00:47 -0800
In article <41e2ee32.4481027@news.sonic.net>,
<whansen_at_corporate-image_dot_com@us.com> wrote:
Top-posting fixed (please don't top-post).
>
> On Fri, 07 Jan 2005 12:29:16 -0800, Jim Gibson
> <jgibson@mail.arc.nasa.gov> wrote:
>
> >In article <41ded263.3951491@news.sonic.net>,
> ><whansen_at_corporate-image_dot_com@us.com> wrote:
> >
[ previous advice on sockets vs. shared memory snipped]
> >
> I'm starting to think that Shareable may be the way to go unless I
> want to go to a server/client connection. I already mentioned that I
> have found a way to use Shareable for communication instead of for the
> actual list and that sped things up a great deal.
>
> A server would work like this:
>
> Server accepts connections on given port. Connection can be just a
> request or a request with a removal. Sever accepts any removals and
> removes them from it's list and then replies with the next data item
> from it's list for the client to run. Disadvantage - each process must
> connect to the server once for each itteration. What happens if the
> server is busy with another process. Advantage - Very exact control
> over the list. The server can easily make sure the list is run evenly
> where the current model uses a randomization so that the processes
> won't all be running the same list in synyc.
>
> Now the server process would be very simple. It just maintains the
> list and gives out the next element. But I wonder if a single process
> could deal well with 150 or more requests per second. I think I'd just
> have to program it and give it a try. Can anyone comment on this? What
> would happen if the server was not avialble? I'm assuming the
> requesting process would just wait for the port to be clear. Again
> this would be much less important in the actual use when it slows down
> to 5 requests per second.
A server can handle only a limited number of queued requests for a
socket connection. The default is 5, The actual maximum number is
system-dependent and may be set by a parameter to the listen()
function. This is the number of connections that are pending but
incomplete. It takes an exchange of 3 IP packets to complete a
connection. If a client attempts to connect to the server while the
number of pending, incomplete connections is equal to the maximum, the
client will likely get a "connection refused" response from the server.
So whether or not the socket server approach will work depends upon 1)
how often a client requests a connection, and 2) how long it takes the
server to complete a client request. Only you have the answers to those
questions.
My money is still on a shared memory solution.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
- Next message: Anno Siegel: "Re: eliminating empty elements of a list"
- Previous message: Jim Gibson: "Re: eliminating empty elements of a list"
- In reply to: whansen_at_corporate-image_dot_com_at_us.com: "Re: IPC looking for simple/best way to communicate"
- Next in thread: xhoster_at_gmail.com: "Re: IPC looking for simple/best way to communicate"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
