[hpsdr] cuSDR on Mac

[Jeremy McDermond]

On Nov 7, 2012, at 12:26 AM, Hermann <hvh.net at gmail.com> wrote:

>> 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.

For what you're trying to do, yes.  It's mainly for things like Apache where you have a group of processes that all want to listen to the same port.  My understanding is (and I haven't tried it; I've had no use for this architecture) that if you have sockets in different processes bound to the same address, the OS *will* multiplex the socket.

>> 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'm not sure how your internal architecture would affect what happened on the wire.  Were you trying to have a single instance of cuSDR talking to multiple HPSDR boxes?

> 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.

There are some OpenGL issues on resize, but that's all I saw on MacOS.  I think this issue is solvable, because I've seen it before with my MacOS code when I was doing something freaky in GL.

I don't think this is a lost cause at all, and while everyone knows my position on cross-platform software I think it's worth having a good one out there for use.  The issue you're running into, IMHO, is that you're catching things that you probably shouldn't be doing on Windows that you're getting away with for various reasons.  They probably should be fixed/rearchitected not only from the perspective of cross-platform compliance, but also that it's probably the right thing to do.  For example in this particular issue, it may not be biting you on Windows now, but if your bind order changes just a little bit, you'll end up breaking the socket code on Windows too.

I have a busy day today, but let me see if I can do some work on the networking code.  I'm fairly experienced with it and am pretty happy with my Mac version, but I really went down to bare metal on that one.  It turns out that Apple's event-driven socket interface really isn't fast enough for what I want to do, so I went down to raw sockets.  I think that the QtUdpSocket interface is looking plenty fast, it just needs some restructuring in the way of the threading.  I can't test on Windows really, but I can send some patches back to you and see what you think.

> So, thanks again Jeremy for this great analysis!
> 
> 73, Hermann
> DL3HVH

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com




 1352290490.0