Most people want access to the raw socket to condition it before it's
passed to POE::Wheel::ReadWrite. ClientConnected is a bit late for
this. As Chris Williams mentioned, by the time ClientConnected is
called, the socket has been conditioned and $_[HEAP]{client} is ready
for action.
The component could provide a ClientConnecting callback that triggers
before ClientConnected and allows the server to manipulate the
socket. ClientConnecting would perhaps return the socket if the
connection should succeed, or return undef to disconnect right away.
$_[HEAP]{client} would be undefined since the POE::Wheel::ReadWrite
hasn't been created yet.
This was considered before, but I think it was rejected for some
reason. I think it was discussed in IRC, and the rationale was lost.
Patches are welcome, but please also include tests and documentation.
If the reason for discounting a ClientConnecting callback still
applies, it might come to light during testing.
Unfortunately it seems that rejecting the connection from
ClientConnecting would still incur the overhead of a POE::Session
instantiation and destruction. ClientConnecting must be called from
the context of the per-connection session.
Applications with more specific requirements should take advantage of
POE::Wheel::SocketFactory and POE::Wheel::ReadWrite directly. These
wheels provide more control and performance, with the trade-off being
incrementally more application code.
Sorry for being all formal. I still have my Work Head on.
--
Rocco Caputo - rcap...@pobox.com
On Jul 16, 2009, at 07:29, Nick Williams wrote:
Regarding the passing of the socket into clientconnected - I've
wished for
this in the past, in order to be able to modify TCP options on the
socket,
which didn't seem possible in the past... It would be nice if that was
possible to get at this (either via some available API which I just
haven't
noticed, or if these patches provide it at clientconnected time).
Cheers,
Nick.
On Thu, Jul 16, 2009 at 12:06 PM, Chris 'BinGOs' Williams <
ch...@bingosnet.co.uk> wrote:
On Wed, Jul 15, 2009 at 06:59:12PM -0800, Michael Fowler wrote:
On Wed, Jul 15, 2009 at 04:08:48AM -0400, Rocco Caputo wrote:
For starters, $_[ARG0] isn't guaranteed to contain anything in
particular.
Well, it's guaranteed to contain whatever was passed as the 'args'
argument to the POE::Session constructor, right? When the session
is
constructed, 'args' is [ $socket, $client_args ]. That 'args' value
needs to remain, because the POE::Wheel::ReadWrite constructor
needs it.
Having ClientConnected then mirror _start in terms of arguments
seems
reasonable.
I think you're almost right. The correct behavior would be for
ClientArgs to align with @_[ARG0..$#_]. This still breaks current
code,
but it's cleaner.
Well, I don't mind breaking old code, but I think ARG0 being the
socket
should be preserved. Reaching into $heap->{client}-
>get_input_handle
seems awkward. Then again, perhaps it's breaking an abstraction
to have
direct access to the socket outside of POE::Wheel::ReadWrite.
The code I have that actually needs it would benefit from the
clarity of
having the socket passed as ARG0. Whether or not this breaks some
possible future change in something...
--
Michael Fowler
www.shoebox.net
First off, thanks for all the patches, I've applied them all apart
from this one.
And the main reason for that is deciding what is the best course of
action.
( I have no vested interest in POE::Component::Server::TCP myself
so can have a non-partisan view ).
There is a difference between the documented behaviour and the actual
behaviour.
I, personally, can't see the need to pass the socket object to the
ClientConnected handler, and without any evidence whatsoever to
substantiate my claim >:) I'd suggest that no one actually uses
the socket.
ClientConnected would be used to send any initial text to the client
which one would usually use $_[HEAP]{client} for.
Similarly, one might want to find out the TCP connection details,
which are again in the heap $_[HEAP]{remote_ip}, etc.
My pennyworth.
Anyways, I see three options:
a). Make the functionality match the documentation;
b). Make the documentation match the functionality;
c). Do what dngor suggests and flatten ClientArgs, forget the socket
and document as such.
Cheers,
--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk
==========================
