The question of real time versus OS-brokered hardware control is answered typically by your need to control the timing aspect of your various processes. In my experience with NI products, the hardware has sufficient timing control to allow one to use regular OS-brokered control, e.g. LV 8.2 running on a desktop machine running XP.
LV real time is a complication above and beyond the usual need. Make sure that the timing requirements (based on sample rate and response time requirements) force you out of normal control before targeting a real time platform with your application.
Regarding the structure of your code, I think you have the right idea. Generally, you want the data acquisition loop running in a quasi-deterministic fashion (quasi because we start out assuming an ordinary non-real-time operating system) in its own loop. The acq loop could fill shift registers in a functional global (a while loop with uninitialized shift registers forced to execute once for each vi call), which you then access from the event driven loop. The event driven loop would handle button clicks and socket traffic. You would make the data storage in the functional global operate like a FIFO buffer. As always, the number of operations performed in the functional global should be kept to a minimum to insure that the acq loop timing is not adversely affected by the event driven loops.
LabVIEW has some pretty painless ways to share data on a network connection. If your code is part of a course that requires you to build your own client and server, then the structure you indicated seems appropriate. On the other hand, you could let the NI datasocket server broker the data communication and simply publish any indicator's value, accessed through the data operations pull-down menu, allowing any client to access it.
Let me know if you need more detail.
jc
Mac 10.4
LV7.1
CLD
