Chris Knipe writes:
> This is an actual example of a communication stream between a client
> and the perl server, the socket is already established, and
> communication is flowing between the two parties. [C] indicates what
> the client is sending to the server, and [S] indicates the responses
>
On Fri, Aug 29, 2014 at 4:33 AM, Chris Knipe wrote:
> It's times like this that I *really* wish I knew how to code in C - no
> offence to anyone, again. Even in .NET doing something like this is
> almost trivial by using separate event handlers for receiving data
> from the socket - again which
On Friday 29 August 2014 10:33:12 Chris Knipe wrote:
> Unfortunately not (we are talking NNTP specifically here if it isn't
> obvious yet) - and the data rates on the network in terms of the
> stream we're looking at over 1Gbps (generated with the TAKETHIS
> commands). The other seemingly obvious
On Fri, Aug 29, 2014 at 11:20 AM, Carl Inglis wrote:
> Does your communication protocol not include an option to back off the rate
> of transmission? Or could you do something at a lower level and not ACK the
> packets to force retransmission at the TCP level? (Clutching at straws a
> little here)
Hi Chris,
I see your point, but everything I've found, both historically in my own
work, and on the web, has been multi-thread, or even multi-process.
For example, where I work at the moment we've got an application which runs
on a series of monitoring equipment and dumps status to a disk file ev
On Fri, Aug 29, 2014 at 10:43 AM, Carl Inglis wrote:
> Hi Chris,
>
> The only way this is going to work as far as I can see is some form of
> multi-threading - how about you have a thread which issues the commands, a
> thread which reads from the sockets and shoves the results into a queue, and
>
Hi Chris,
The only way this is going to work as far as I can see is some form of
multi-threading - how about you have a thread which issues the commands, a
thread which reads from the sockets and shoves the results into a queue,
and another thread which processes that queue.
I think you're lookin
And this is effectively what I WANT to happen...
[C] TAKETHIS
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User"
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Exa
On Fri, Aug 29, 2014 at 10:10 AM, Carl Inglis wrote:
> I suspect you're looking for something like this:
> http://www.perlmonks.org/?node_id=66135
>
> In fact, it's specifically mentioned in the Perl Cookbook:
> http://docstore.mik.ua/orelly/perl/cookbook/ch07_15.htm
The comments on the first URL
On Fri, Aug 29, 2014 at 1:18 AM, Sam wrote:
> Are you saying the normal 'unix' way won't work? (ie. listen on socket, fork
> on an accepted connection, do the work, close)
Oh - and yes, if that is the 'unix' way, then yes, it's unacceptable.
The socket CANNOT be torn down after each and every sin
I'm not sure if there's a misunderstanding somewhere (which may be mine).
As I understand it what you want to do is launch a command towards the
server, and then another, and then another, all the time waiting for a
response to one or more of your commands.
I suspect you're looking for something
On Fri, Aug 29, 2014 at 1:18 AM, Sam wrote:
> Are you saying the normal 'unix' way won't work? (ie. listen on socket, fork
> on an accepted connection, do the work, close)
Not at all. My problem is not related to creating, accepting, or
forking at all.
The block / waiting occurs whilst the soc
On 08/28/2014 09:19 AM, Chris Knipe wrote:
Hi All,
I’ve looked at Net::Server (and have my “new” server with some 20K lines
of code written in it that we’re currently finalising), POE, and a few
other things, but I cannot find what I am looking for… I’m hoping for
some assistance / pointers plea
Hi All,
I've looked at Net::Server (and have my "new" server with some 20K lines of
code written in it that we're currently finalising), POE, and a few other
things, but I cannot find what I am looking for. I'm hoping for some
assistance / pointers please. I am looking for the following simple
14 matches
Mail list logo