Re: [Edbrowse-dev] One program Two processes

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

On Sat, Dec 26, 2015 at 10:23:40AM -0500, Karl Dahlke wrote:
> > I'd go for UDP rather than TCP for local IPC,
> 
> Imagine one edbrowse-ht process, the one with the curl space,
> that does all the http https and ftp fetches.
> edbrowse connects to edbrowse-ht and says
> "fetch this big http file and return it to me,
> don't just download it I want it in memory, so return it to me."
> edbrowse-ht pulls down a hundred meg file and sends it
> back to edbrowse over socket,
> but we need perfect fidelity here, we need the continuity
> and certainty of the stream.
> If we don't use tcp we'll have to reinvent most of it,
> so we may as well use tcp, at least for this instance
> and probably for most of our communications.

Not necesarily. I think you'd want to use temp files for something like that,
otherwise the IPC logic gets complicated.
> udp is fine for packet voice and such in that if you miss some packets you don't care,
> it's barely a click in the sound, but here we need all the bits in
> exactly the right order.

Also, packet loss over a local loopback connection shouldn't happen,
so that's not really an issue either.
From the work I've done with scalable IPC stuff in the past I'd go for a
combined approach of having udp command and response and then temp files for
large downloads. Sure we then have to read back into memory but that makes much
more sense to me than implementing TCP-based IPC in this case.
Also, for the case of most pages, this wouldn't be too much of an issue.

The alternative is a comms process which either has to do tcp multiplexing in a
single thread or has to be multi-threaded even before you get to the comms stuff.
That's going to be awkward to get right.

Cheers,
Adam.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]