On Fri, Sep 07, 2001 at 11:54:54AM -0700, Rob Bloodgood wrote:
>
[...]
> My UDP server is slightly different, and I think it accurately reflects the
> differences between TCP/UDP without hurting the above mental image too much.
>
>
> Instead of using S::TCP to create the sockets and then deal with them, my
> UDP server just comes into being (CountBouncer->new())... and new() just
> wraps POE::Session->new() anyway... should we call it spawn()? :-).
Probably spawn(), unless you're returning an object reference that
anybody should care about. :)
> But _start, instead of a wheel wrapped around a new, connected socket, is a
> wheel wrapped around a LISTENING socket. Big difference here. Incoming
> messages are all handled by the same state... or, incoming messages all
> trigger the same event:
>
> sub got_socket {
> delete $heap->{wheel};
> $heap->{socket_handle} = $socket;
> $kernel->select_read( $socket, 'got_message' );
> }
If it's a UDP socket, it's not really listening for connections.
Instead, it's just open and sitting around waiting for connectionless
packets. That's peer-to-peer instead of connected socket sessions.
Several "clients" can interact with the same UDP handle. Because it's
connectionless, every new read must include a peer address/port pair
so you know where it came from. With TCP you can assume (within
reason) that everything is coming from the client that was originally
accept()'ed.
> But... but... ?? I wrote it months ago, after stealing it from the examples,
> and now I'm *really* confused. How can I delete the wheel (which started
> this chain of events) and still accept incoming UDP messages, unless I've
> transparently spawned a new POE::Session??
UDP SocketFactory is just used to create sockets. Once the UDP socket
is built, you don't need the wheel anymore. The same for client TCP
sockets, where the wheel's not going to create any new sockets after
the connect() has completed. To initiate a new connection (or start a
new UDP socket), you create a new wheel.
Your session doesn't go away because the select_read() call tells
POE::Kernel to watch the filehandle for activity. This is also what
happens in Wheel::ReadWrite.
UDP sockets have very little Wheel support because they don't work the
way normal sockets do. ReadWrite is more attuned to the needs of
connected sockets than peer sockets, for instance. It's that
assumption that you know who's on the other end of a socket. Wheels
don't pass the peer information around because it's usually not
necessary.
So... how about a UDP wheel?
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
