You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't a problem in and of itself, especially considering that the compile-time option renders all of QlipperNetwork's functions essentially no-ops, but what seems a little weird is that a port is immediately bound:
It seems to me that keeping networking ports closed unless needed is a generally good philosophy overall, but especially with "experimental" networking support. Making that binding conditional to one of the two preferences seems a lot more sensible.
The text was updated successfully, but these errors were encountered:
So, we've had network support since version 2.0.2 thanks to 8982c03. It's documented as experimental and off by default in CMakeLists.txt:
qlipper/CMakeLists.txt
Line 50 in 302e2d1
Similarly, even if you compile support in, the related preferences are off by default:
qlipper/src/qlipperpreferences.cpp
Lines 226 to 234 in 302e2d1
However,
QlipperModel
immediately callsQlipperNetwork
:qlipper/src/qlippermodel.cpp
Lines 31 to 34 in 302e2d1
This isn't a problem in and of itself, especially considering that the compile-time option renders all of
QlipperNetwork
's functions essentially no-ops, but what seems a little weird is that a port is immediately bound:qlipper/src/qlippernetwork.cpp
Lines 53 to 55 in 302e2d1
It seems to me that keeping networking ports closed unless needed is a generally good philosophy overall, but especially with "experimental" networking support. Making that binding conditional to one of the two preferences seems a lot more sensible.
The text was updated successfully, but these errors were encountered: