[apps] Fix broken TcpMedium of srt-tunnel in windows

[sorayuki]

close(fd), write(fd, ...) and read(fd, ...) are not suitable for socket operation in Windows.
I have changed them to closesocket, send and read, while use read/write for other platforms to prevent sigpipe signal.

why use shutdown for tcp_close:
that is what udpcommon class in transmitmedia.cpp does.

[sorayuki]

I find the tunnel very easy to freeze in Windows.

It is freezed in a waiting-chain like this.

The main thread, which is waiting for a slow recv of another socket indirectly, stops accepting new incoming connections.

[ethouris]

Deadlocks like that typically happen in case when a thread is expected to exit by itself, and that's why it's being joined, but by some reason it doesn't exit.

Would you be able to run it with -v option and make it freeze? How easy is it to make it?

[sorayuki]

The structure is like this:

The browser, the 2 tunnels and the proxy are running in the same machine.

And these are log files:
log.zip

It's very easy to make it by visiting some foreign website in browser.
It doesn't happen if browser connect to the proxy without the 2 tunnels.

I'm currently not very sure if the problem caused by my win32-porting or not.

[sorayuki]

code is edited, and rebased to lastest master branch.
Add setsockopts in case of SIGPIPE

[ethouris]

MSG_NOSIGNAL is not a flag settable by setsockopt. It's a flag that should be passed in send function in the last argument.

[ethouris]

https://stackoverflow.com/questions/26752649/so-nosigpipe-was-not-decleared

It is also recommended that if this is simply a standalone application (not a library), you can simply disable the SIGPIPE signal.

[ethouris]

Please fix the MSG_NOSIGNAL call

[sorayuki]

Done.
I have got no Linux or MacOS environment at the minute. I'd like to rely on your CI system to check if it builds.

According to How to prevent SIGPIPEs (or handle them properly), neither MSG_NOSIGNAL nor SO_NOSIGPIPE is portable.

Another problem, I found cmake fail to generator nmakefile since commit 291bdf2d97bc23444a24fdd505ffdee7134e70e9, unless I change the last line of srtcore/filelist.maf from ../version.h to version.h.

CMake commandline is

cmake -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded
	  -DCMAKE_POLICY_DEFAULT_CMP0091=NEW 
	  -DCMAKE_PREFIX_PATH="C:/Users/SoraYuki/source/repos/srt_build/dist" 
	  -G "NMake Makefiles" 
	  -DCMAKE_BUILD_TYPE=Release
	  -DCMAKE_INSTALL_PREFIX="C:/Users/SoraYuki/source/repos/srt_build/dist"
	  -S "C:/Users/SoraYuki/source/repos/srt_build/srt"
	  -B "C:/Users/SoraYuki/source/repos/srt_build/srt/build"
	  -DUSE_ENCLIB=mbedtls
	  -DENABLE_SHARED=ON 
	  -DENABLE_APPS=0
	  -DENABLE_STATIC=OFF

It reports

-- Configuring done
CMake Error at CMakeLists.txt:615 (add_library):
  Cannot find source file:

	C:/Users/SoraYuki/source/repos/srt_build/srt/version.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


CMake Error at CMakeLists.txt:615 (add_library):
  No SOURCES given to target: srt_shared

In fact the file is located in C:/Users/SoraYuki/source/repos/srt_build/srt/build

After the changes, I have tried not to use -S and -B, just use . as what CI script does. It also works.

[ethouris]

Placing version.h file in the filelist.maf file is completely wrong. I don't know how it slipped through my hands, but this couldn't work. The "maf" system is intended to provide STATIC list of files located at the exactly pointed location, relative to the directory where the filelist.maf file is located. The build directory location is to be decided dynamically. Adding this file makes the build broken, ALWAYS, either direct or shadow build, depending on which path you use.

Not sure how to approach this change, but if you figure out how to make the build system work without this version.h in filelist.maf, I will be grateful. If this file REALLY needs to be added to the file list, it better be added directly in CMakeLists.txt near the place where the configure_file call occurs.

[maxsharabayko]

Placing version.h file in the filelist.maf file is completely wrong. I don't know how it slipped through my hands, but this couldn't work

Slipped in PR #639

[maxsharabayko]

filelist.maf fix in #960

[maxsharabayko]

@sorayuki Please update the PR against master branch (conflicting changes).

[sorayuki]

done