RPC interface to get random numbers

[Duss Pirmin]

Spam detection software, running on the system "idefix.duss.local",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview: Hello We have different components in our system that require
random numbers. So our idea is to implement an RPC interface that allows
one component to provide random numbers and an other to receive them. [...]


Content analysis details: (7.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or
Generic rPTR
2.9 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split
IP)
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[92.106.180.179 listed in dnsbl.sorbs.net]
3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[92.106.180.179 listed in zen.spamhaus.org]
0.4 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS

[Norman Feske]

Hello Pirmin,

thanks for posting your idea to the list.

I wonder, have you considered to implement the random service as a
"Terminal" service that just produces a stream of random values? The
benefit would be that such a server can be combined with the existing
terminal infrastructure out of the box. For example, you could mount the
random server's session in the VFS (via a <terminal> node) without any
extra effort.

The rationale behind keeping the number of session interfaces as low as
possible is given at the beginning of Chapter 4 "Components" in the
documentation. Please excuse me blatantly citing myself ;-)

"The versatility of a component-based system does not come from the
existence of many components alone. Even more important is the
composability of components. Components can be combined only if their
interfaces match. To maximize composability, the number of interfaces
throughout the system should be as low as possible, and all interfaces
should be largely orthogonal to each other. Section 4.5 reviews
Genode’s common session interfaces."

So before starting to create a new interface, I always recommend to
double check if the problem can be modeled via the existing interfaces.
In most cases, this is possible. Sometimes, a combination of two
interfaces does the trick. E.g., instead of equipping a session with the
ability to request meta information directly from the server, it is
often possible to let the server generate a report about its feature set
(via the "Report" session) and let the client request this information
as a ROM session. This out-of-band propagation of configuration data is
much more flexible and better testable.

Cheers
Norman
--
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------

[Duss Pirmin]

Spam detection software, running on the system "idefix.duss.local",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Hello Pirmin, > > thanks for posting your idea to the list. > > I wonder,

have you considered to implement the random service as a > "Terminal" service
that just produces a stream of random values? The > benefit would be that
such a server can be combined with the existing > terminal infrastructure
out of the box. For example, you could mount the > random server's session
in the VFS (via a <terminal> node) without any > extra effort. [...]

Content analysis details: (7.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or
Generic rPTR
2.9 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split
IP)
3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[92.106.180.179 listed in zen.spamhaus.org]
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[92.106.180.179 listed in dnsbl.sorbs.net]
0.4 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS