[fpc-pascal] lnet for TCP daemon
Mark Morgan Lloyd
markMLl.fpc-pascal at telemetry.co.uk
Thu Sep 12 12:47:12 CEST 2013
Mark Morgan Lloyd wrote:
> Michael Schnell wrote:
>> On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
>>> I'd normally use a thread for this, but I've already got lnet's
>>> telnet client running in the program so would rather stick to the
>>> same library if possible.
>>>
>>
>> AFAIK, Lnet does not do threading internally (as does AsyncPro or -
>> partly - Indy), so if you need to wait for TCP input while doing other
>> things in your program, you need to do your own thread, anyway.
>
> [Nod] Works adequately for a telnet-based terminal though.
>
>> I switched from Lnet to Synapse lately, as same seems to a lot of
>> provide usable protocols. Synapse does not provide internal threads,
>> either.
>
> True. Synapse's protocol support is second to none, but in the current
> case there's really no protocol involved- grab/store data and that's it.
If I understand from more Googling etc., lnet server support works by
the program first setting up a server socket and applying Listen, then
setting up a connection socket and calling Accept() with the server
socket (possibly the server socket's handle, and I'm unsure how to get
this) as parameter. Both of these would need CallAction calls on a
regular basis.
I've concluded that using a thread is, in fact, preferable since I don't
know how much data will arrive from the far end, how it will be paced,
and whether the far end might attempt multiple simultaneous connections.
While a polling scheme is OK for the foreground terminal stuff there's
too much change that its proliferation will mess up either foreground or
background transfer.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-pascal
mailing list