[hpsdr] cuSDR on Mac

[Hermann]

Thanks a lot for your analysis, Jeremy!

On Wed, Nov 7, 2012 at 1:26 AM, Jeremy McDermond <mcdermj at xenotropic.com>wrote:

> On Nov 6, 2012, at 12:16 PM, Hermann <hvh.net at gmail.com> wrote:
>
> > Probably some of the socket options have to be adjusted for OSx. The
> device discovery is done in cusdr_hpsdrIO.cpp, whereas the data start/stop
> and communication you can find in the cusdr_dataEngine.cpp. The methods
> sendInitFramesToNetworkDevice and networkDeviceStartStop uses their own
> sockets.
>
> This is the crux of your problem.  You can't bind two sockets to the same
> address on UNIX-ish systems and have it work correctly.  What happens is
> that the last socket bound gets all the incoming IO from the kernel.  When
> cuSDR first starts up, it starts the thread for DataReceiver and puts the
> hook in its event loop to catch when there's data waiting.  You then
> immediately thereafter go and execute the networkDeviceStartStop which
> binds another socket to the same address.  This causes all of the inbound
> data to that address to be directed towards this new socket.  As soon as
> you're done sending, you then close the socket which makes the OS ignore
> any subsequent inbound data.  SO_REUSEADDR doesn't solve this for you.
>  Sockets can't multiplex like this on any UNIX-ish system I'm aware of.
>
> I found a post with GoogleFu (
> http://www.qtforum.org/article/36875/many-qudpsocket-listening-at-the-same-port-have-different-behavior-in-win7-and-ubuntu.html)
> that seems to explain the difference.  On WIndows the *first* socket bound
> to the address keeps all of the input.  On UNIX the *last* socket bound
> keeps all of the input.
>

This is really a strange difference between these worlds. I found also
another thread where this problem is addressed:
http://qt-project.org/forums/viewthread/8708
And I think I have to understand what SO_REUSEADDR really means then. At
the moment it seems pretty useless to me.


>
> QtUdpSocket really only wants to be owned and operated by a single thread
> so you really can't just send stuff willy nilly to it off of other threads,
> even though that may be thread safe around a mutex or something.  What
> really should happen is that a single object should hold the socket and do
> any sending/receiving that needs to happen on it.
>

OK, this questions my architecture at least for the use on Linux/MacOS. If
you look in older versions of cusdr_HPSDRIO.cpp you will see that this
class was intended to be the single object where all IO is done. I don't
remember exactly what was the problem, but I do remember that I had
problems in working with more than one HPSDR client in the LAN (I had two
Metis and two Hermes running at the same time in my local network). My
focus was always safe multi-threading, and now I have to learn that there
is - so to speak -  another notion of 're-entrance' wrt sockets on Windows
and Unix-like OSs Anyway, I will try to work out the necessary changes.

I think these issues can be solved. But still there are the questions on
the overall GUI appearance/behavior of platform-independent code. We had
this discussion earlier, and I very well remember your opinion on that,
which I can understand very well. My first impression on my Linux box,
although these were just very early steps into it, were very discouraging -
not to talk about the OpenGL issues I saw.

So, thanks again Jeremy for this great analysis!

73, Hermann
DL3HVH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20121107/01fba79a/attachment-0004.htm>