[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