in reply to non-blocking TCP/IP client object using callbacks

I don't quite see what your overall question is, but to answer some of the bits:

No theres no Net::Telnet::Callbacks that I know of, and I really wouldn't recommend Net::Telnet for anything than talking to real telnet servers (maybe I'm biased tho, I don't like it..) Although, telnet has options, and Net::Telnet does event stuff based on those, I think.

Sockets would be a good idea, you could write that easy to do callbacks.

Threads are a bit of a pain together with Sockets etc. (In my experience), I've a fairly complicated telnet/mud client using 5.005 threads, which is complicated enough, but still not managed to convert to ithreads, which are more difficult to use (and dont allow sharing of objects) ..

Theres some IO::Socket stuff on castaway's scratchpad if you need a starter on that (the im2 script).

(No experience with/knowledge of IPC::SysV, and no idea why you shouldn't use Sockets :)

I can give you a link to my (rather bulky and also flaky), telnet client with modules, events and all sorts of junk, if you'd like :)

C.

  • Comment on Re: non-blocking TCP/IP client object using callbacks

Replies are listed 'Best First'.
Re: Re: non-blocking TCP/IP client object using callbacks
by jettero (Monsignor) on Jul 22, 2003 at 12:14 UTC
    No, I'm not really afraid of socket programming either. I failed to explain myself is all. I had actually planned on having to clarify. I'm just not very good with the english... Meh.

    The question is really: What's the best way to implement a client object that can read and write to a socket, but that passes control back to the caller, and that passes received lines back to the caller via a set of function callbacks.

    So far, I rather think I'll end up doing this with IPC and a fork() because it'll be the most portable. Well, I'm not 100% on that. Does IPC and fork even work on windows? I wouldn't know. But I do know that threads don't work everywhere.

[reply]
      Perhaps the caller could periodically pass the controll back to the socket listener? Thus you would not need the parallelism whis is allways a bit tricky.
[reply]
        That won't probably work quite right. Since the caller will probably be Curses, or GTK or something, control needs to be with the UI nearly all the time.

        If you ever got stuck in a blocking getline or something, the UI would be very irritating. Anyway, I had considered that. But if you want to release a module that other people are likely to use... then you have to do the hard work for them. :)

        I just asked about this here, because I wanted to make sure what I was doing was ... a good way to do it.

[reply]

In Section Seekers of Perl Wisdom