ken@gvax.cs.cornell.edu (Ken Birman) (06/12/90)
With some help from Scott Schwartz, we've come up with the following approach to using XDR within ISIS messages. Basically, the idea is to use XDR to stream data into a memory area (allocated dynamically) and then put it into an ISIS message using the %*C format (pointer to an array of characters), with size obtained using the XDR routine xdr_getpos. One funny thing about XDR streams is that they come in different flavors. Some, like xdrstdio, automagically write to files (or sockets, of course), so short of reading the file there is no way to capture the contents of the stream. There is an xdrrec flavor that lets the user supply the routines to be called on record boundaries, so you could save up the output and then read it on the other end in the same way. Finally, there is an xdrmem flavor that writes to a xdrmem, XDR stream used with memory object chunk of memory. That last form is the one to use if you need to employ XDR within ISIS. The idea is to generate XDR output inside a memory area, then put the resulting encoded data into your message using %C or, to avoid copying, %*C. On reception, a pointer to the data can be obtained using the %+C format. It is easy to hack up an xdrmem_resize, xdr_resize, change size of an XDR data object which you can use when an XDR write fails to make the buffer bigger. If you are using xdrmem streams, xdr_getpos seems to return the size xdr_getpos, size of an XDR data object (in bytes) of the stream, although it is not clear if this behavior is guaranteed for all possible XDR implementations. ... does anyone know enough about NDR to describe the corresponding mechanism?