Suggestion to design specific network client

[Francesco Vollero]

Hi,

as in the object i need to realize a simple IPv6 multicast client. And I
already do it with some troubles but solved.
Now, i've to make something that every N seconds, i.e. 10s , store the
data sampled until that moment and start doing other operations, but i
dont have to stop the sampling action. The sampling operation have to be
like a while true.
I dont have any clue to accomplish that. I was thinkin to use
eventmachine but i dont know if i can apply my custom setsockopts and i
did not find any documentation about it.

Thanks in advance,

Francesco Vollero

 

[Caleb Clausen]

Hi,

as in the object i need to realize a simple IPv6 multicast client. And I
already do it with some troubles but solved.
Now, i've to make something that every N seconds, i.e. 10s , store the
data sampled until that moment and start doing other operations, but i
dont have to stop the sampling action. The sampling operation have to be
like a while true.
I dont have any clue to accomplish that. I was thinkin to use
eventmachine but i dont know if i can apply my custom setsockopts and i
did not find any documentation about it.

Um, maybe use threads? EventMachine ought to work too, but I can't
speak to that.

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.

HTH

 

[Francesco Vollero]

Il 29/05/10 00.05, Caleb Clausen ha scritto:

Um, maybe use threads? EventMachine ought to work too, but I can't
speak to that.

Hi again,

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.

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

HTH

-Francesco

 

[Caleb Clausen]

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.

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.