On Mon, 24 Mar 2003 21:24:32 -0500, Mark G <[EMAIL PROTECTED]> wrote:

Hello Stefan,

Ok, I replied to the previous response to my post and it apparently didn't
go through, but it's irrelevant anyway. (My response to the "why bother"
was summed up with "so I can learn how it's done.")



good point, although why not build the socket your self [ you can even pack
raw sockets if you wish ]??

Because, as I already stated :) I've already learned how to do the socket stuff with previous projects... otherwise I would :)


When I do the sockets this way, it waits for input on the $dccsocket
without
moving on to work on the information from the $socket until I send a /dcc
close
chat $mybotsnick... After I close the DCC CHAT connection, it reads from
the $socket again without problem... I've change this recently to:


in the snipet you send there is no code to handle "/dcc close".

The XChat handles that. When I tell XChat "/dcc close chat Botnick" it closes the socket connection.

behavior you explained fallows as your code. I think the only reason you are
geting past the read , is because $dccsocket points to a non valid handle.

No... when I have it set in blocking mode, it reads from the DCC socket just fine, so it's NOT an invalid handle... it just doesn't send to the $socket anymore until I close the $dccsocket.

If you have warnings enabled you should get a message.

>With the
$socket->blocking(0) and the sysread() calls, I should be able
to read without problems from either one, but now it fails to even open
the
$dccsocket.

ok before I answare that, dont mix blocking IO with NON_blocking IO[ print
on socket, stdio and all high level io functions use there own buffering
scheme ] atleast $|=1 on top of your script should disable stdlib buffering,
I woudl avoid print and <> in general for NON-BLOCKING IO.
I figured print statements were ok, since I don't care about blocking on
the output to the buffers.  The only reason I care whether it's blocking
at all is that I thought the blocking reads might have been why the $socket
wasn't being read anymore (while the $dccsocket reads worked)

print $socket "PRIVMSG $channel $dcctmp\r";
are you sure all data got send over this socket ?? maybe the server has
closed your socket by now ?? or maybe it couldnt handle the whole message ??
The server did not close the $socket because the $socket works again after
closing the $dccsocket, the program just doesn't send the information down
the $socket anymore while reading from $dccsocket (in blocking mode)

If I was you I would select() to make sure socket is ready for read. check
sysread if it return anything or $! might be EWOULDBLOCK.
As I stated before, I found examples on the use of Select, but all of
the examples were for a server, not a client, and the selects were
designed for the "accept()" call... I haven't done enough work with
select to figure out how to make it work the way I want it to, so
basically... I don't know how to use that particular feature. If
you or someone else can give a working example of IO::Select()or
it's lower level counterpart, (in a client situation, NOT a server
situation) I'd love to see it, so I can learn what it really
does :)

$data="PRIVMSG $channel $dcctmp\r";
Why did we set $data equal to anything if we are reading information
into it from the server? just curious :)

$status=sysread($socket,$data,$max_buff);
if( defined $status){
if($status >0){print "full read of $status bytes on socket" if
$debug); }
else{ print "recieved EOF on socket\n" if $debug; }
}
elsif($! == EWOULDBLOCK){warn "socket no read to be read yet\r\r";#handle
how you wish }
else{ warn "error on socket: $!"; }



bypass the router and neither one works.  The second may be due to
the way XChat opens it's socket.  If it bound it to listen on a
specific IP then it may not be listening to localhost and I wouldn't be
able to connect, but the only IP it should listen on
if that's the case is my '192.168.x.x' IP from my router.  I
tried setting to that IP as well with no luck

could be, if you want send me your IP and i'll give it a run.

I'm pretty sure it's not the router... it didn't work from work today either... and there isn't a NAT issue there.

What I don't understand is WHY it's not able to create the socket
with the given information. (on the nonblocking version)

Thank you for taking the time to look at my code, and thank you
for your suggestions.  I know this is a big project to be taking
on, but each time I make a mistake, I learn 2 or 3 new things and
that's exactly why I started this project.  I appreciate the
time taken to help me with this.
Respectfully,
Stefan

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to