# Intercommunicate processes **URL:** \ **Category:** GNU Radio\ **Created:** [July 30, 2012, 10:34am UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772 "2012-07-30T10:34:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [July 30, 2012, 10:34am UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772/1 "2012-07-30T10:34:55Z")
Dear list, I would need to communicate two separated gnuradio programs. I tried to use udp\_sink / udp\_source in the same machine but there are many many packets lost. Is there a way to use a kind of sink/source without losses to communicate separated programs in Windows? I also tried to use a tcp stack to obtain a fileno and then use file\_descriptor\_source/sink but in windows is not possible to use read/write on a socket descriptor (you can only use recv/send). So I need to find another solution but I don’t know how to solve it. Thanks for your help. – Pol H. Research Engineer, MSc removed\_email\_address@domain.invalid Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC) Engineering Unit Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 7 08860 Castelldefels, Barcelona (Spain) Tel: +34 93 396 71 70 Ext: 2177 Fax. +34 93 645 29 01 www.cttc.es ---
**Author:** ![Pol\_H](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@Pol\_H](https://www.ruby-forum.com/u/Pol_H)\ **Post date:** [July 30, 2012, 1:46pm UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772/2 "2012-07-30T13:46:35Z")
On Mon, Jul 30, 2012 at 4:33 AM, Pol H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > need to find another solution but I don’t know how to solve it. > > Thanks for your help. > > – > > Pol H. Pol, What kind of packet losses are you seeing? It shouldn’t be that high, but UDP gives you no guarantee that packets won’t be dropped or even show up in order. Still, for loopback, I would expect less than 1% packet loss rate (I think that I’m being overly pessimistic, but I’ve heard reports for more), so I’m more just curious what kind of performance you’re seeing on Windows. You could try to recreate the UDP source/sink as TCP, instead. But if you have the same kinds of losses, just know that with the retransmissions, you’re going to have to slow things down. If you were on Linux, I’d suggest using FIFOs on a RAM disk, but I’m not sure you can do that in Windows. Tom ---
**Author:** ![Pol\_H](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@Pol\_H](https://www.ruby-forum.com/u/Pol_H)\ **Post date:** [July 31, 2012, 7:03am UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772/3 "2012-07-31T07:03:20Z")
> I also tried to use a tcp stack to obtain a fileno and then use > file\_descriptor\_source/sink but in windows is not possible to use > read/write on a socket descriptor (you can only use recv/send). So I > need to find another solution but I don’t know how to solve it. if it helps, there is a tcp socket block in GrExtras. Using blob to/from socket with blob to/from stream might do the trick for you I happen to have a screenshot of the block: > **[Home](https://github.com/guruofquality/grextras/wiki#wiki-a-demonstrative-screen-cap)** > > Advanced GNU Radio Blocks. Contribute to guruofquality/grextras development by creating an account on GitHub. -josh ---
**Author:** ![Pol\_H](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@Pol\_H](https://www.ruby-forum.com/u/Pol_H)\ **Post date:** [August 2, 2012, 3:11am UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772/4 "2012-08-02T03:11:48Z")
On Wed, Aug 1, 2012 at 3:19 AM, Pol H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > are the following connections: > problem with hier\_block2. > Pol H. > Research Engineer, MSc > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Pol, That’s concerning. Any chance you can produce a simple graph using existing blocks in GNU radio to help us examine this problem? Thanks, Tom ---
**Author:** ![Pol\_H](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@Pol\_H](https://www.ruby-forum.com/u/Pol_H)\ **Post date:** [August 1, 2012, 9:20am UTC](https://www.ruby-forum.com/t/intercommunicate-processes/221772/5 "2012-08-01T09:20:33Z")
Dear Tom, Even though the loses are low, I would like to do not lose any sample. I implemented a sink/source block using shared memory and I can guarantee that there are no loses. However I discovered a deeper problem. There is a strange behaviour with hier\_block2. I test the following topoly: A → B → C → D, where B and C are sink/source blocks (using shared memory or udp, it does not matter, they are basic blocks). A and D are a CRC encoder and decoder but in a hier\_block2. In more detail, in A there are the following connections: Data\_Generator → CRC\_attacher → self D is the reciprocal block. CRC\_attacher is also a hier\_block2 in the following way: self → CRC\_compute → self Hence, I use a hier\_block2 inside another one. Yes, I know I could use CRC\_compute without being encapsulated in the hier\_block2 but in the future will be additional blocks. With this topology there are CRC fails. If I use CRC\_compute without hier\_block2 all CRC decodings are ok. So it seems there is a rare problem with hier\_block2. I read a similar problem in [http://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00061.html](http://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00061.html) and therefore I put a kludge\_copy after/before self connections. But the problem still occurs. What could it be? Thanks. Pol H. Research Engineer, MSc removed\_email\_address@domain.invalid Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC) Engineering Unit Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 7 08860 Castelldefels, Barcelona (Spain) Tel: +34 93 396 71 70 Ext: 2177 Fax. +34 93 645 29 01 www.cttc.es El 30/07/2012 13:44, Tom R. escribi: