Network packet loss possible inside the linux kernel?

Hello folks!

I am currently planning to implement an easy way to communicate between
multiple processes on the local machine. Every process may sends events
(in form of a null terminated string) as multicast UDP messages. The
other processes react on these events if required.

How likely is it, that packet loss may occur? My hope is, that because
these messages are processed without a physical network, that I can
ignore the packet loss issue.

If there is a problem, can you give me some hints about alternatives?
Just a few keywords, I can use google for further information.

Regards,
Daniel Kay

Daniel Kay wrote:
> Hello folks!
>
> I am currently planning to implement an easy way to communicate between
> multiple processes on the local machine. Every process may sends events
> (in form of a null terminated string) as multicast UDP messages. The
> other processes react on these events if required.
>
> How likely is it, that packet loss may occur? My hope is, that because
> these messages are processed without a physical network, that I can
> ignore the packet loss issue.
>
> If there is a problem, can you give me some hints about alternatives?
> Just a few keywords, I can use google for further information.
>

The protocol stack can still silently drop packets,
if it feels the need to.

You can flood the networking buffers by sending far
more packets than you receive. This may happen because
the sending process/thread runs on higher priority
than the receiving one.

--

Tauno Voipio
tauno voipio (at) iki fi

On Sat, 22 Sep 2007 08:44:55 +0200, Daniel Kay rearranged some electrons
to say:

> Hello folks!
>
> I am currently planning to implement an easy way to communicate between
> multiple processes on the local machine. Every process may sends events
> (in form of a null terminated string) as multicast UDP messages. The
> other processes react on these events if required.

Have you considered the interprocess communications features already
found in *nix?

http://tldp.org/LDP/lpg/node7.html

david wrote:
> On Sat, 22 Sep 2007 08:44:55 +0200, Daniel Kay rearranged some electrons
> to say:
>
>> Hello folks!
>>
>> I am currently planning to implement an easy way to communicate between
>> multiple processes on the local machine. Every process may sends events
>> (in form of a null terminated string) as multicast UDP messages. The
>> other processes react on these events if required.
>
> Have you considered the interprocess communications features already
> found in *nix?
>
> http://tldp.org/LDP/lpg/node7.html

I think using pipes and fifos are an easy and simple way to communicate
between two processes. But I don't see any easy way using these
mechanisms for communication between multiple processes. I can't fork,
and I don't want to open a named pipe in every communication direction.

I do not have much experience with System V IPC. And using shared memory
is dangerous, which could block the whole communication, if one process
with a lock on a semaphore/mutex crashes.

If you disagree with the text above, please tell me of... :-)

I am considering writing an TCP/IP daemon, to which all processes
connect. This process will route every incoming message/event to all
other processes, if they have registered for the message.


Regards,
Daniel Kay

On Sat, 22 Sep 2007 19:20:28 +0200, Daniel Kay rearranged some electrons
to say:

> david wrote:
>> On Sat, 22 Sep 2007 08:44:55 +0200, Daniel Kay rearranged some
>> electrons to say:
>>
>>> Hello folks!
>>>
>>> I am currently planning to implement an easy way to communicate
>>> between multiple processes on the local machine. Every process may
>>> sends events (in form of a null terminated string) as multicast UDP
>>> messages. The other processes react on these events if required.
>>
>> Have you considered the interprocess communications features already
>> found in *nix?
>>
>> http://tldp.org/LDP/lpg/node7.html
>
> I think using pipes and fifos are an easy and simple way to communicate
> between two processes. But I don't see any easy way using these
> mechanisms for communication between multiple processes. I can't fork,
> and I don't want to open a named pipe in every communication direction.
>
> I do not have much experience with System V IPC. And using shared memory
> is dangerous, which could block the whole communication, if one process
> with a lock on a semaphore/mutex crashes.

Look at message queues, that might do what you want.

Daniel Kay <daniel-(E-Mail Removed)> wrote:
> Hello folks!

> I am currently planning to implement an easy way to communicate
> between multiple processes on the local machine. Every process may
> sends events (in form of a null terminated string) as multicast UDP
> messages. The other processes react on these events if required.

> How likely is it, that packet loss may occur? My hope is, that
> because these messages are processed without a physical network,
> that I can ignore the packet loss issue.

It can happen and you should assume it will. Here is just a plain
unidirectional test showing a few losses:

hpcpc105:~/netperf2_trunk# src/netperf -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec

124928 65507 10.01 205949 0 10784.03
124928 10.01 205946 10783.87

hpcpc105:~/netperf2_trunk# uname -a
Linux hpcpc105 2.6.23-rc3-minrtoms #1 SMP Tue Aug 21 15:21:54 PDT 2007 ia64 GNU/Linux

And it does not require sending anything particularly large:

hpcpc105:~/netperf2_trunk# src/netperf -t UDP_STREAM -- -m 1460
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec

124928 1460 10.01 1792715 0 2092.08
124928 10.01 1790784 2089.83

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...