My first question is whether “we” [those able] could attempt to create a block diagram initially including, say, the various “technologies” involved [e.g pipes / sockets / both?] and perhaps describing which chdkptp source file(s) [to level of section line numbers ?] enable that functionality.
I don't know about diagrams, but I can try to outline the basic organization.
https://www.assembla.com/spaces/chdkptp/wiki/Scripting_Guide may also be help you get oriented. Discussion here may help me expand it.
I don't think getting to the line number level is useful, at that point you need to understand the actual code, and the best way to do that is to read it.
The main chdkptp code is loosely organized into several layers.
Going roughly from lowest level to highest:
1) ptp.c
Handles ptp communication and some of the connection management functionality. This code was originally inherited from the ptp.c in in ptpcam, but has been substantially modified. The ptp_chdk_* functions generally handle complete PTP transaction involving one of the CHDK PTP extension opcodes defined in chdk_headers/core/ptp.h. Each of these functions takes a PTPParams argument, which includes everything related to the specific connection. Multiple connections are handled just by passing a different connection.
2) chdkptp.c
Provides the ptp related Lua APIs, and also handles some transport specific setup (USB or PTP/IP) and some miscellaneous functionality.
The Lua APIs are chdk.* and chdk_connection.*. These are described some in the wiki page linked above. Together, they provide everything that the rest of chdkptp uses to talk to the cameras. Most of the chdk_connection methods correspond to one of the ptp_chdk_* functions in ptp.c.
Connections are stored in the lua "registry" table by bus/device (or ip/port), so there is a single "connection" object for each connected camera.
3) chdku.lua
Provides more user friendly "wrapper" for the connection object and APIs provided by chdkptp.c, along with a bunch of higher level functions and utilities. It provides methods for executing code, waiting for the results, handling script messages, remote capture and so on. It relies on the rlibs.lua library to manage camera side code.
After this, you get to several different "front ends" that all use chdku for most of their interaction with the camera.
cli.lua
Implements the command interpreter and most of the cli commands like upload, download etc. cli commands can also be executed from code. Unlike the preceding levels, the CLI has a single, current connection that it operates on.
multicam.lua
maintains lists of cameras and allows calling the same functions across all of them. More on this later, maybe.
gui.lua (+ the other gui_*.lua files)
all the GUI stuff
In addition to these, there are a number of support libraries that are used by one or more of the above.
rlibs.lua mentioned above is probably worth describing a little. It implements a system for managing camera side code. Individual "modules" are defined as tables with the camera code in a string, and other fields to define dependencies. rlibs:build creates a single string that can be sent to the camera including the desired modules and all dependencies. This is used by the chdku exec* functions.
Some chdkptp modules like multicam and rsint add additional rlib modules.
As far as "technologies" go, chdkptp just uses libusb, or sockets for PTP/IP. chdkptp is currently single threaded, so although you can have multiple connections, you can only do one transaction at time, and the actual transaction blocks everything else until it's done.