This post contains responses to questions from multiple previous posts from multiple people. Hopefully it won't get too confusing.
Let me try and shed some light on the BufferMaxBytes and BufferMaxPackets properties. The term packets is a little cryptic, and it's probably easier if you think of packets as the number of elements written through the DataSocket Write VI. If BufferMaxPackets is set to 10 and you write elements of type double, the client buffer will grow and hold at most 10 doubles. The BufferMaxBytes property works in conjunction with the BufferMaxPackets property to limit the maximum size of the client buffer. In effect, they act as a floor function. Continuing with the previous example, if BufferMaxBytes was set to 72, the client buffer would only be able to hold up to 9 elements instead of 10 since 9 doubles will consume 72 bytes worth of space. This isn't particularly useful for scalar data types, but it becomes more important for data types like arrays, strings, clusters, and waveform data types. For these data types, an individual element (or packet) can be very small (1D array of size 2) or very large (1D array of size 1,000,000). In this case, it's often more convenient to limit the maximum size in terms of bytes rather than packets. The example VIs located at <LV Dir>\examples\comm\datasktbuf.llb do a reasonable job of demonstrating how these two settings can effect streaming performance and whether or not data gets lost or overwritten.
If you're using waveform data type (WDT) or arrays as your element type, each write constitutes a packet or element of data and packets are never combined. This means if you write four 1D array elements of size 250, you will always read four 1D array elements of size 250 on the other end. You can't collapse the packets and read a single 1D array of size 1000. This is true for both the PSP (Shared Variable) or DSTP protocol. Collapsing can be accomplished to a degree with network streams since it supports both single element and multi-element reads and writes. In this case, you would configure the element type of the stream to be a double and use the multi-element read/write to vary the number of elements read and written on each side. If you set the element type of the stream to 1D array and use the single element read/write, you'll get the same behavior you do with the PSP and DSTP protocol. However, it still won't work for WDT natively. To do this, we'd have to track the dt, t0, and number of samples included in each waveform element and make sure the written elements were contiguous such that they could be read out in smaller or larger chunks than they were written into the stream. This is a pretty expensive operation to perform with each read and write which is why didn't try to support it. If you know your data is contiguous, it's always going to be more efficient for you to transfer the t0 and dt up front and simply deal with the array portion of the WDT from there on out.
You can use the DataSocket VIs to read and write items published by either the PSP or DSTP protocol and enable client side buffering for either protocol. To do this, you have to remember to set the BufferMaxPackets and BufferMaxBytes properties described above as well as set the appropriate mode on the Open VI to enable buffering for just reads or for both reads and writes on the connection. If you're using the Dynamic Variable API, you can only read/write points published through the PSP protocol. In LV 2010, you can now set the size of the client side buffer by using the Open and Verify Variable Connection or Open Variable Connection in Background VIs located on the PSP Variable palette. In this case, the buffer size is always in units of elements, and both reads and writes are buffered using the same buffer size setting. Finally, for buffering to be effective, you also have to enable buffering on the server. For Shared Variables, this is set on the properties page when you right click on the Variable item in the LabVIEW project. For items published through the DSTM protocol, this is set in the DataSocket Server Manager. For predefined items, you can uniquely configure the maximum size in bytes and packets for each item. Non-predefined items all share the same configuration for the maximum size in bytes and packets. In either case, the default value is 26214400 bytes and 1 packet so double check to make sure the number of packets is larger than 1 if you want to enable buffering on the client connections and have it be effective. You can get away with no buffering on the server or the writer if you're using synchronous writes (timeout > 0) that complete before timing out. However, if you're using asynchronous writes, you should at a minimum enable buffering on the server if not both the writer and the server.
Some final parting shots: If you end up going down the road of trying to write your own buffer object, you might want to look at <LV DIR>\examples\general\globals.llb\Smart Buffer (DBL).vi. I think it might already support the functionality you were trying to implement at one time. If not, it should be a pretty good starting point. If network streams provide what you want aside from the client/server aspect, you could try writing your own server that you deploy that negotiates with clients and then gives them the information they need to establish the peer to peer connection for the network stream. I realize it's probably more work than you wanted, but it might still be better than the other options in front of you. Something to think about...
(mawahaha!)
