search

gnieboer / GNURadio_Windows_Build_Scripts

A series of Powershell scripts to automatically download, build from source, and install GNURadio and -all- it's dependencies as 64-bit native binaries then package as an msi using Visual Studio 2015
GNU General Public License v3.0
89 stars 33 forks source link

TCP sink/source crash on connection #15

Closed ErezAviv closed 7 years ago

ErezAviv commented 7 years ago

Using GRC TCP client sink block on one PC and TCP server source block on another PC, tried both on Windows 8.1 and Windows 10, when TCP source connects to TCP sink the Python crashes

gnieboer commented 7 years ago

This is an issue with an SO_LINGER flag being used, and is a bug in the GNURadio code (that manifests on Windows only). It will be worked there but I will keep this open for tracking purposes EDIT: Correction, the bug I referenced was for a UDP source/sink error. I have reproduced your TCP issue and will investigate.

ErezAviv commented 7 years ago

I am not sure if it will help investigating - when running GRC i get this : \ (python.exe:7616): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'

ghostop14 commented 7 years ago

I'm running into the same issue. Same config, latest 3.7.10.1 Windows binary install. Doesn't happen on linux, just Windows. It's actually a problem for me since my hardware-installed OS is Windows and I'm trying to work with some SDR hardware and use the TCP sink to pipe the data over to a linux VM for some post-processing (the post-processing app is expecting the TCP sink connection).

Is there any workaround or ETA on a bugfix!

Thanks!

ghostop14 commented 7 years ago

I hunted down the source of the error but I don't know python well enough to fix it. In tcp.py in _get_sock_fd there's a return of sock.fileno(). This call appears to not be available on Windows.

Here's a test case: Start a listener on any port, say 5000, then try to run this code on linux and Windows. Windows will always return "Bad file descriptor".

import socket import os addr="127.0.0.1" port=5000 sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM) sock.connect((addr, port)) print(os.dup(sock.fileno()))

gnieboer commented 7 years ago

Thanks for that, very helpful. I had been able to debug the UDP source/sink, but hadn't much luck w/ the TCP side. I will do some research and see what I can find as far as a good fix.

On Tue, Dec 6, 2016 at 1:18 PM, ghostop14 notifications@github.com wrote:

I hunted down the source of the error but I don't know python well enough to fix it. In tcp.py in _get_sock_fd there's a return of sock.fileno(). This call appears to not be available on Windows.

Here's a test case: Start a listener on any port, say 5000, then try to run this code on linux and Windows. Windows will always return "Bad file descriptor".

import socket import os addr="127.0.0.1" port=5000 sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM) sock.connect((addr, port)) print(os.dup(sock.fileno()))

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gnieboer/GNURadio_Windows_Build_Scripts/issues/15#issuecomment-265228177, or mute the thread https://github.com/notifications/unsubscribe-auth/ADErafOT3H5qVuGUTiGN2-4-ES6cxhmFks5rFabhgaJpZM4KL4a4 .

ghostop14 commented 7 years ago

Thanks Geof, that would be awesome. I talked with the creator of the SDR tool I had mentioned and he said the UDP connection just wasn't reliable enough for the data communications, so TCP is still the way to go.

gnieboer commented 7 years ago

Well, there's the good news and the bad news... Good news, I clearly see the issue and what's going on. Bad news, fixing it requires a complete rewrite of the TCP source/sink code

Basically, the TCP sink works by treating the socket as a file descriptor, and opening a file descriptor sink/source behind the scenes. That works in Unix, but not in Windows. It's a difference at the OS level, not the python level. So we'd have to rewrite the block in C with separate code for WinSock2 sockets and Unix sockets. Not impossible, but not a small bug fix.

ghostop14 commented 7 years ago

I think the good news/bad news nails it! That's what I saw too as I was reading some of the blogs.

Someone commented that the implementation hadn't been updated since like 2006 and seemed more proof-of-concept than robust. Sounds like the UDP source/sink was completely rewritten with async I/O like it should be but they never touched the TCP in favor of going to the ZeroMQ.

I think for the legacy apps out there (and how quick/easy a simple TCP source/sink is) it's very much worth keeping in gnuradio and the effort to modernize it (that's my way of pleading that it's worth the effort :)).

Unfortunately my development experience is all Windows and .Net or I'd help out. Is there anything in the UDP rewrite code that can just be copied and tweaked to change the socket type over to TCP (I know server code can be a bit more tricky with tracking client connections)? Or at least start as a foundation?

gnieboer commented 7 years ago

TCP source/sink shows deprecated in GRC 3.7.11 for all platforms so closing this as "won't fix"