bzfs is publicizing when invoked without -public

Tegan · Post by **Tegan** » Mon Jul 05, 2004 3:57 pm

It seems to me as if -publicaddr without -public is making bzfs
list itself publicly, and also that bzfs segfaults when run without
-publicaddr. That's two problems. I think a simple code change
should both fix the first one and render the second an easy workaround.
Hopefully this can be confirmed or disproved, so here it is...

In bzfs/CmdLineOptions.cxx, there is a line which reads
"options.publicizeServer = true;" in the block which handles
the "-public" option. That's good, but then it appears again in the block which
handles "-publicaddr". Shouldn't this only be done for "-public"?

Commenting out the suspect line in the "-publicaddr" block enables running
a private server by invoking without "-public", or a public server
by invoking with "-public", as advertised, but only as long as (and
here is the aforementioned workaround...) the "-publicaddr" option
is supplied on invocation.

So hopefully someone can tell whether this is the way to solve the problem,
or even if the problem exists as such.

Lan · Post by **Lan** » Mon Jul 05, 2004 7:36 pm

As for the public problem, add "-q" to make a server private. This makes it not contact the list server.

Post by **DTRemenak** » Mon Jul 05, 2004 9:10 pm

Lan56: -q does not have anything to do with the list server, it makes the server not respond to query pings, which are used for locating servers on lans.
To clarify, there are two ways the client locates servers. One is retrieving the server list. The other is a UDP broadcast ping, which will locate even "non-publicized" servers on a local segment.
Servers do not add themselves to the list by default (they do if you add -public), but they do respond to pings by default (unless you add -q). The list server list is accessible internet-wide, but broadcast pings won't propogate past most routers, so that list is limited to clients on your LAN or sometimes the same segment of your ISP's network.

Tegan: publicaddr turning on public is probably by design, as it is only used to tell the list server what the "external" address of the server is. if the client can reach the server via a udp broadcast ping, it doesn't need an additional address; same if the address is typed in by the remote user.
I can't duplicate the segfault, what's the full command line you're using?

Tegan · Post by **Tegan** » Mon Jul 05, 2004 9:32 pm

It was my understanding that -public is the way to list a server,
too, but that is not exactly hat I observed. The following examples
might help. Output is condensed for brevity.

trial #1, simple invocation

$ bzfs -d -q -p 5156
style: 0
(shows the voting arbiter info, but no server info, then...)
Segmentation fault

trial #2

$ bzfs -d -q -p 5166 -publicaddr bzflag.sleepycows.us:5166
style: 0
(shows the voting arbiter info)
(shows PUBLIC server info, even though -public is not used.)

trial #3
After commenting out the line "options.publicizeServer = true;"
in bzfs/CmdLineOptions.cxx, the one in the -publicaddr code block.

$ bzfs -d -q -p 5166 -publicaddr bzflag.sleepycows.us:5166
style: 0
(voting blah blah)
(YES!!! It runs a PRIVATE server.)

trial #4
Same as trial #3 but with -public, it now runs a public server.

It segfaults if -publicaddr is omitted in any case, which I
haven't figured out yet.

It may not be a real bug, could be my own error or something in
my environment; though a simple code change seems to fix it, as far
as I can tell.