Re: Suggestion to design specific network client

On 5/28/10, Francesco Vollero <[e-mail]> wrote:
> yes i can use threads but, now i was wondering would a good idea to
> apply the Observer pattern in order to "fire" the other operations and
> keep going sampling data.

An observer feels wrong, idunno. Observer is not a
thread-synchronization mechanism, AFAIK.

I see 2 threads. The first gathers data and puts it into big buffers.
It sends those buffers to the second thread over a Queue. The second
thread waits on the Queue for buffers to come in and when they arrive
summarizes them (or whatever you're doing) and ships them out again.
Probably first thread needs to be higher priority, assuming it doesn't
need to run all the time and spends a significant amount of time
sleeping.

>> What is this sampling that you're doing? What kind of samples are they
>> and more importantly, where do they come from? You're gonna need some
>> kind of (hardware or software) buffering in order to ensure that no
>> samples get lost. The size of that buffer lets you know how long your
>> program can 'go away' and do other things (like network i/o) before
>> you start losing data.
>>
>>
> The samplings are UDP broadcast messages between many nodes and contain
> values gathered from sensors mounted in all nodes. All samples are the
> same, i want to collect it and after that operation create a bundle
> packages of collected data to another machine at regular intervals. All
> those nodes are into a local network. Sensor data are sent as Fixnum.
>
> I hope to be clear enough to explain my problem, feel free to ask
> everything, because your questions give me the opportunity to rethink
> about it :)

So in this case the lowest level buffer is the network card's input
queue. If that buffer overflows, packets will drop and you'll lose
data. This will work fine as long as you don't max out either your
network or your cpu. If either one peaks, you'll risk data loss.
Depending on how much data you're moving around, this may or may not
be a problem.