Yes, I see your point. Socket output maps well to ImageOutput, but socket
input is different than ImageInput (because the socket doesn't necessarily
exist at all, or yet).
We may need some kind of helper function that implements the "listen for a
connection" part, and when that says that a connection is ready, then we can
open the socket ImageInput and pass it a hint that gives the specific name or
port number or whatever to read from. We need not strictly restrict ourselves
to the existing ImageInput interface; it's ok to add something socket-specific
to get things started. It need not be generic; any app listening to sockets is
going to damn well know that's what it's doing. But once the socket is
established, it would be nice if the rest of the interface for actually reading
the pixels from the socket was through the II.
Another thing that needs to be shoehorned in is that the socket may not
communicate pixels in scanline or tile order, and aren't necessarily ready at
any given time. We'll need a way to ask the socket connection if another
scanline or tile is ready, and which one it is. We may be able to use the
existing send_to_input()/send_to_client() mechanism for this; it's in place for
this kind of thing but so far has not been used.
-- lg
On Jun 9, 2012, at 12:50 AM, Chad Dombrova wrote:
> Hi all,
> I mentioned in an email earlier that I have a rough prototype of socket
> rendering working via oiio into iv. The purpose of this email is that I am
> having trouble making the socket rendering model fit within the oiio
> "open/read/close" ImageInput model. At first glance they may seem compatible
> -- open a socket connection, read the tile data, close the connection -- but
> there are serious problems lurking once you dig deeper.
>
> Consider the typical socket rendering scenario:
>
> 1. start a listening server
> 2. on connect from client, create a new image buffer
> 3. read tiles from client into buffer
> 4. close connection
> 5. repeat steps 3-4 (possibly at the same time)
>
> In this scenario, there is a single server listening on another thread all of
> the time: before, after, and during a socket render. The server handles all
> incoming connections and creates the SocketInput instances, which handle the
> remainder of the data streaming for that connection. In the
> "open/read/close" model, on the other hand, each SocketInput acts as its own
> server, valid for a single connection only. What this means is that a new
> SocketInput must be created *prior* to each new render performed. I'm very
> opposed to placing this burden on the user, but performing the convoluted
> code trickery in IV required to lift that burden is not attractive either.
>
> There is other fallout as well. For example, in the ideal/typical scenario,
> when the server accepts a connection from a renderer, the first thing it does
> is get the filename of the image about to be sent. though the image does not
> exist on disk, the file name serves both as a unique handle in the case of
> multiple simultaneous renders, and as something useful to display in IV to
> identify the image. Since the name can't be changed once the ImageInput is
> created, we would either force the user to enter in a new name prior to each
> render or use the same name for all socket images.
>
> So, what is the best solution? Perhaps we could abstract the server model
> down to an "image generator": a function that runs on a separate thread and
> generates new ImageInput instances. plugins could register these generator
> functions, if they apply. Are there any other file formats that would
> benefit from some kind of abstracted server model? I'm really not sure what
> else could benefit from such a thing, but I'm trying to work within the
> plugin framework to avoid treating sockets as a special case.
>
> Any guidance on this would be greatly appreciated.
>
> -chad
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
