From MusicMastaMike at aol.com Mon Nov 2 14:57:18 2009 From: MusicMastaMike at aol.com (Michael Stegeman) Date: Mon, 02 Nov 2009 13:57:18 -0600 Subject: [Spread-users] Adding IPv6 Support Message-ID: <4AEF399E.1050203@aol.com> Hi all, I'm new to this list and have read through the archives regarding this topic, but I'm wondering what would be involved in adding IPv6 support to Spread? I'm willing to do the work myself (or with help, if anyone is willing), but I'd like to get a feel for how much work this would entail. -Mike From phelpsw at gmail.com Fri Nov 6 20:22:35 2009 From: phelpsw at gmail.com (Phelps Williams) Date: Fri, 6 Nov 2009 17:22:35 -0800 Subject: [Spread-users] Formal description of Ordering and Delivery Guarantees Message-ID: <685b25860911061722u7b56a7eft6052a20c17c9a148@mail.gmail.com> Hello, I am interested in how exactly spread provides ordering and delivery guarantees when a SAFE type message is transmitted to a group. I have reviewed the documentation and spread related publications and have been unable to find a clear description of this process. I would prefer not to dig through the source code and reverse engineer the functionality. Am I not looking in the correct places? Thank you. -Phelps From matthew.garman at gmail.com Tue Nov 10 18:25:40 2009 From: matthew.garman at gmail.com (Matt Garman) Date: Tue, 10 Nov 2009 17:25:40 -0600 Subject: [Spread-users] spread through firewall? Message-ID: <20091110232540.GA31678@sewage> Hi, We would like to open the smallest possible hole in our firewall to allow spread connections. What ports need to be open, and what type should they be (tcp/udp)? For example, say I'm running a spread daemon on channel 4803. I obviously need TCP port 4803 open. But I believe spread uses additional ports as well---which ones? Thank you! Matt From jschultz at spreadconcepts.com Tue Nov 10 23:44:43 2009 From: jschultz at spreadconcepts.com (John Schultz) Date: Tue, 10 Nov 2009 23:44:43 -0500 Subject: [Spread-users] spread through firewall? In-Reply-To: <20091110232540.GA31678@sewage> References: <20091110232540.GA31678@sewage> Message-ID: <70E5194D-4C5F-46E1-A55A-4F83398E80AD@spreadconcepts.com> It also uses UDP 4803 and UDP 4804. If you want spmonitor to work remotely, then you will also need to open UDP 4805. Cheers! ----- John Lane Schultz Spread Concepts LLC Phn: 301 830 8100 Cell: 443 838 2200 On Nov 10, 2009, at 6:25 PM, Matt Garman wrote: Hi, We would like to open the smallest possible hole in our firewall to allow spread connections. What ports need to be open, and what type should they be (tcp/udp)? For example, say I'm running a spread daemon on channel 4803. I obviously need TCP port 4803 open. But I believe spread uses additional ports as well---which ones? Thank you! Matt _______________________________________________ Spread-users mailing list Spread-users at lists.spread.org http://lists.spread.org/mailman/listinfo/spread-users From jschultz at spreadconcepts.com Tue Nov 10 23:57:26 2009 From: jschultz at spreadconcepts.com (John Schultz) Date: Tue, 10 Nov 2009 23:57:26 -0500 Subject: [Spread-users] spread through firewall? In-Reply-To: <70E5194D-4C5F-46E1-A55A-4F83398E80AD@spreadconcepts.com> References: <20091110232540.GA31678@sewage> <70E5194D-4C5F-46E1-A55A-4F83398E80AD@spreadconcepts.com> Message-ID: <0BEA7B8D-2A17-4EFB-9E9C-0528776CDF1A@spreadconcepts.com> Sorry for the spam, but more generally if you instruct Spread to use port X, then it uses: TCP Port X UDP Port X UDP Port X + 1 UDP Port X + 2 (spmonitor) Cheers! ----- John Lane Schultz Spread Concepts LLC Phn: 301 830 8100 Cell: 443 838 2200 On Nov 10, 2009, at 11:44 PM, John Schultz wrote: It also uses UDP 4803 and UDP 4804. If you want spmonitor to work remotely, then you will also need to open UDP 4805. Cheers! ----- John Lane Schultz Spread Concepts LLC Phn: 301 830 8100 Cell: 443 838 2200 On Nov 10, 2009, at 6:25 PM, Matt Garman wrote: Hi, We would like to open the smallest possible hole in our firewall to allow spread connections. What ports need to be open, and what type should they be (tcp/udp)? For example, say I'm running a spread daemon on channel 4803. I obviously need TCP port 4803 open. But I believe spread uses additional ports as well---which ones? Thank you! Matt _______________________________________________ Spread-users mailing list Spread-users at lists.spread.org http://lists.spread.org/mailman/listinfo/spread-users _______________________________________________ Spread-users mailing list Spread-users at lists.spread.org http://lists.spread.org/mailman/listinfo/spread-users From matthew.garman at gmail.com Wed Nov 11 10:00:22 2009 From: matthew.garman at gmail.com (Matt Garman) Date: Wed, 11 Nov 2009 09:00:22 -0600 Subject: [Spread-users] spread through firewall? In-Reply-To: <0BEA7B8D-2A17-4EFB-9E9C-0528776CDF1A@spreadconcepts.com> References: <20091110232540.GA31678@sewage> <70E5194D-4C5F-46E1-A55A-4F83398E80AD@spreadconcepts.com> <0BEA7B8D-2A17-4EFB-9E9C-0528776CDF1A@spreadconcepts.com> Message-ID: <20091111150022.GA29538@sewage> On Tue, Nov 10, 2009 at 11:57:26PM -0500, John Schultz wrote: > Sorry for the spam, but more generally if you instruct Spread to > use port X, then it uses: > > TCP Port X > UDP Port X > UDP Port X + 1 > UDP Port X + 2 (spmonitor) I consider this useful information, not spam! :) Thank you for your quick and helpful replies, Matt From rich at noir.com Tue Nov 17 13:14:59 2009 From: rich at noir.com (K. Richard Pixley) Date: Tue, 17 Nov 2009 10:14:59 -0800 Subject: [Spread-users] Intro Message-ID: <4B02E823.1030201@noir.com> Hello. The intro doc asked me to introduce myself so here I am. I'm a spread newbie, but not entirely a newbie to virtual synchrony. Back in the 80's, I wrote a distributed wall street ticker plant, (Sequent Balance, Sequent Symmetry, Sun 3/50's, later Decstations), and later rewrote it in ISIS. But that's been a few years ago now and the spread doc seems a bit lean in terms of background info by comparison to what I remember from ISIS. Questions... Has anyone made any noise about updating the debian/ubuntu packages to spread version 4? They seem to be a few years out of date, I'm in a position to volunteer the work, and I'll need packages anyway if I go through with my upcoming project using spread. Also, using the python-spread package currently available on debian/ubuntu, how do I tell the ordinality/seniority of a group member? Is that just something I need to track on my own and ship to joining processes as new state? Here's a situation I'm unsure of. I'm looking to create redundant, distributed state here. A process is running and it sends a state change message at the same time as a second process joins. Upon receiving the join message, the first process will send a state dump to the second process. However, if the state dump message is formulated and sent prior to receiving the state change message, then isn't it conceivable that the messages will be received in the "join", "state change", "state dump" order effectively losing the "state change" message for the second process? Is there a guarantee I'm overlooking here? Or is there a standard way to deal with this situation? --rich From rich at noir.com Tue Nov 17 16:36:12 2009 From: rich at noir.com (K. Richard Pixley) Date: Tue, 17 Nov 2009 13:36:12 -0800 Subject: [Spread-users] Intro In-Reply-To: <4B02E823.1030201@noir.com> References: <4B02E823.1030201@noir.com> Message-ID: <4B03174C.5000400@noir.com> K. Richard Pixley wrote: > Is there a guarantee I'm overlooking here? Or is there a standard way > to deal with this situation? Never mind on this one. A few hours later and I've figured out that I need a lock on state changes here. I'm still interested in hearing about upgraded debian/ubuntu packages. --rich From cbbrowne at ca.afilias.info Tue Nov 17 17:18:18 2009 From: cbbrowne at ca.afilias.info (Christopher Browne) Date: Tue, 17 Nov 2009 17:18:18 -0500 Subject: [Spread-users] Intro In-Reply-To: <4B02E823.1030201@noir.com> (K. Richard Pixley's message of "Tue, 17 Nov 2009 10:14:59 -0800") References: <4B02E823.1030201@noir.com> Message-ID: <87ocn0bxsl.fsf@dba2.int.libertyrms.com> "K. Richard Pixley" writes: > Has anyone made any noise about updating the debian/ubuntu packages to > spread version 4? They seem to be a few years out of date, I'm in a > position to volunteer the work, and I'll need packages anyway if I go > through with my upcoming project using spread. I reported a bug on this a while back... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469173 Quoting the relevant bits: ----------------------------------------------------------------------------- there are at least 2 problems where help is needed: - there are API changes in spread v4, libspread has a higher major version number than in v3 (2 vs. 1). - in spread v3 we built 4 packages from source tarball: * spread, * libspread1, * libspread1-dev, * libspread-perl. In spread v4 tarballs the perl stuff is not longer included, so libspread-perl will disappear unless we build it from CPAN or from spread's svn (CPAN has the more recent version) in a seperate package. Should one build a package providing - spread, - libspread2, - libspread2-dev conflicting with libspread1/libspread1-dev? And let "Debian Perl Group" handle the libspread-perl? ----------------------------------------------------------------------------- -- select 'cbbrowne' || '@' || 'ca.afilias.info'; Christopher Browne "Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three" From bcarey at jambomedia.com Fri Nov 20 08:46:25 2009 From: bcarey at jambomedia.com (Brian Carey) Date: Fri, 20 Nov 2009 08:46:25 -0500 Subject: [Spread-users] Building 64-bit on Solaris 10 (x86_64) Message-ID: <4B069DB1.8090000@jambomedia.com> Hi all, I've successfully built the 4.1.0 source in 32-bit mode, however, when trying to build 64-bit binaries it fails. Below are my configure options and errors from the build process (I can provide entire build output if necessary, but for now I just included the blocks of errors). I'm using the Sun GCC packages. Does anyone have any suggestions on what i'm doing wrong? I see in previous mailing list posts people mentioning building this 64-bit on Solaris so i'm assuming its possible. Thanks in advance for any help you can provide. GCC Specs ----------------------- Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Configure options ----------------------- ./configure --prefix=/opt/spread_64 --with-cflags=-m64 --with-ldflags=-m64 Build Errors ----------------------- gcc -o spread spread.o protocol.o session.o groups.o alarm.o events.o memory.o membership.o data_link.o network.o status.o log.o flow_control.o message.o lex.yy.o y.tab.o configuration.o acm.o acp-permit.o auth-null.o auth-ip.o ../stdutil/lib/libstdutil-threaded-release.a -m64 -lm -lrt -lsocket -lnsl ld: warning: file ../stdutil/lib/libstdutil-threaded-release.a(stdarr.to): wrong ELF class: ELFCLASS32 Undefined first referenced symbol in file stdskl_it_key groups.o stdskl_is_end groups.o stdarr_push_back groups.o stdarr_empty groups.o stdskl_size groups.o stdskl_find groups.o stdskl_put_seq_n groups.o stdarr_destruct groups.o stdskl_destruct groups.o stdskl_begin groups.o stdskl_empty groups.o stdskl_erase groups.o stdarr_size groups.o stdskl_put groups.o stdskl_end groups.o stdskl_it_next groups.o stdarr_pop_back groups.o stdarr_construct groups.o stdskl_construct groups.o ld: fatal: Symbol referencing errors. No output written to spread collect2: ld returned 1 exit status make[1]: *** [spread] Error 1 make[1]: Leaving directory `/opt/src/spread-src-4.1.0/daemon' make[1]: Entering directory `/opt/src/spread-src-4.1.0/docs' ../buildtools/fixpaths: input file ./SP_connect.0 missing! make[1]: *** [SP_connect.3.out] Error 2 make[1]: Leaving directory `/opt/src/spread-src-4.1.0/docs' make[1]: Entering directory `/opt/src/spread-src-4.1.0/libspread' . . . gcc -shared -o libspread.so fl.tlo scatp.tlo alarm.tlo events.tlo memory.tlo sp.tlo -m64 ../stdutil/src/stdarr.lto ../stdutil/src/stdcarr.lto ../stdutil/src/stddll.lto ../stdutil/src/stderror.lto ../stdutil/src/stdfd.lto ../stdutil/src/stdhash.lto ../stdutil/src/stdit.lto ../stdutil/src/stdskl.lto ../stdutil/src/stdthread.lto ../stdutil/src/stdtime.lto ../stdutil/src/stdutil.lto -lm -lrt -lsocket -lnsl -lposix4 -lthread -lpthread -Wl,-hlibspread.so.2 ld: fatal: file ../stdutil/src/stdarr.lto: wrong ELF class: ELFCLASS32 ld: fatal: File processing errors. No output written to libspread.so collect2: ld returned 1 exit status make[1]: *** [libspread.so] Error 1 make[1]: Leaving directory `/opt/src/spread-src-4.1.0/libspread' make[1]: Entering directory `/opt/src/spread-src-4.1.0/examples' . . . gcc -m64 -o flush_user fl_user.to ../libspread/libspread.a -lm -lrt -lsocket -lnsl -lposix4 -lthread -lpthread Undefined first referenced symbol in file stdhash_erase_key ../libspread/libspread.a(fl.to) stdmutex_destruct ../libspread/libspread.a(fl.to) stddll_is_end ../libspread/libspread.a(fl.to) stddll_it_val ../libspread/libspread.a(fl.to) stdhash_is_end ../libspread/libspread.a(fl.to) stdhash_it_val ../libspread/libspread.a(fl.to) stdhash_it_key ../libspread/libspread.a(fl.to) stderr_output ../libspread/libspread.a(fl.to) stdhcode_sfh ../libspread/libspread.a(fl.to) stdhash_destruct ../libspread/libspread.a(fl.to) stddll_push_back ../libspread/libspread.a(fl.to) stdcond_wait ../libspread/libspread.a(fl.to) stddll_size ../libspread/libspread.a(fl.to) stdcond_construct ../libspread/libspread.a(fl.to) stddll_destruct ../libspread/libspread.a(fl.to) stdmutex_grab ../libspread/libspread.a(fl.to) stdmutex_drop ../libspread/libspread.a(fl.to) stdcond_destruct ../libspread/libspread.a(fl.to) stddll_begin ../libspread/libspread.a(fl.to) stddll_empty ../libspread/libspread.a(fl.to) stddll_clear ../libspread/libspread.a(fl.to) stddll_erase ../libspread/libspread.a(fl.to) stdmutex_construct ../libspread/libspread.a(fl.to) stdhash_begin ../libspread/libspread.a(fl.to) stdhash_empty ../libspread/libspread.a(fl.to) stdhash_erase ../libspread/libspread.a(fl.to) stddll_it_next ../libspread/libspread.a(fl.to) stdhash_it_next ../libspread/libspread.a(fl.to) stdflip32 ../libspread/libspread.a(fl.to) stdflip16 ../libspread/libspread.a(fl.to) stdhash_construct ../libspread/libspread.a(fl.to) stdhash_copy_construct ../libspread/libspread.a(fl.to) stdcond_wake_all ../libspread/libspread.a(fl.to) stdhash_size ../libspread/libspread.a(fl.to) stdhash_find ../libspread/libspread.a(fl.to) stddll_construct ../libspread/libspread.a(fl.to) stdhash_insert ../libspread/libspread.a(fl.to) ld: fatal: Symbol referencing errors. No output written to flush_user collect2: ld returned 1 exit status make[1]: *** [flush_user] Error 1 make[1]: Leaving directory `/opt/src/spread-src-4.1.0/examples' make: *** [all] Error 2 From neal at walfield.org Sat Nov 21 11:11:54 2009 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 21 Nov 2009 17:11:54 +0100 Subject: [Spread-users] segmentation fault in spmonitor's option parser Message-ID: <87pr7b7t85.wl%neal@walfield.org> spmonitor is very sloppy about option parsing. For instance, if you don't supply a mandatory argument to an option, it crashes. The attached patch corrects this. It also prints out that an option is unknown when this is the case. This latter change is arguably a separate change but it related in the sense that the patch prints out that a mandatory option is missing, if this is the case, and changes this error scenario to act similarly. Relatedly, for reading the port argument, sscanf is used but no validation check is performed. In the very least, I think one ought to check if MY_PORT has the value 0 and error out in this case. I have not included a patch to change this behavior. Neal 2009-11-21 Neal H. Walfield * monitor.c (Usage): Don't segmentation fault if a mandatory option is missing. If a flag is unknown, say so. diff -c /home/neal/src/spread-src-4.1.0/daemon/monitor.c\~ /home/neal/src/spread-src-4.1.0/daemon/monitor.c --- /home/neal/src/spread-src-4.1.0/daemon/monitor.c~ 2009-06-18 22:24:17.000000000 +0200 +++ /home/neal/src/spread-src-4.1.0/daemon/monitor.c 2009-11-21 16:59:26.000000000 +0100 @@ -1075,6 +1075,7 @@ static void Usage(int argc, char *argv[]) { + char *error = NULL; My_name = 0; /* NULL */ My_port = 6543; @@ -1087,7 +1088,9 @@ { argv++; - if( !strncmp( *argv, "-p", 2 ) ) + if (argc == 1) + error = "Option missing mandatory argument."; + else if( !strncmp( *argv, "-p", 2 ) ) { sscanf(argv[1], "%d", &My_port ); @@ -1112,8 +1115,12 @@ strcpy( Config_file, argv[1] ); argc--; argv++; - }else{ - Alarm( EXIT, "Usage: spmonitor\n%s\n%s\n%s\n%s\n", + }else + error = "Unknown option."; + + if (error) { + Alarm( EXIT, "%s\nUsage: spmonitor\n%s\n%s\n%s\n%s\n", + error, "\t[-p ]: specify port number", "\t[-n ] : force computer name", "\t[-t ]: specify number of seconds between status queries", Diff finished. Sat Nov 21 17:00:23 2009 From bcarey at jambomedia.com Mon Nov 23 08:13:29 2009 From: bcarey at jambomedia.com (Brian Carey) Date: Mon, 23 Nov 2009 08:13:29 -0500 Subject: [Spread-users] Building 64-bit on Solaris 10 (x86_64) In-Reply-To: <200911210530.nAL5U1mK000614@aragorn.savarese.org> References: <200911210530.nAL5U1mK000614@aragorn.savarese.org> Message-ID: <4B0A8A79.40300@jambomedia.com> Thank you very much, I had already made the fix to the configure script so once I used the options you specified it built like a charm. - Brian dfs at savarese.org wrote: > In message <4B069DB1.8090000 at jambomedia.com>, Brian Carey writes: > >> I've successfully built the 4.1.0 source in 32-bit mode, however, when >> trying to build 64-bit binaries it fails. Below are my configure >> > ... > >> I'm using the Sun GCC packages. Does anyone have any suggestions on >> what i'm doing wrong? I see in previous mailing list posts people >> > > The build system doesn't propagate all configure options to subpackages. > Try adding CC='gcc -m64' to force the libstdutil build into 64-bit mode. > I just verified the following successfully compiles spread 4.1.0 using > gcc 4.4.0 and binutils 2.19: > > ./configure --prefix=/opt/spread-4.1.0 CC='gcc -m64' CFLAGS='-m64 -O2' LDFLAGS='-m64 -lrt' > > I just tried it again with the stock gcc 3.4.3 (/usr/sfw/bin/gcc) and > the Solaris linker (/usr/ccs/bin/ld) and everything compiled except for > a fatal linker error generating libspread.so.2. However, the static > libraries and spread binary built without error. The stock gcc in > /usr/sfw uses the Solaris linker, which doesn't grok the -soname option > passed to it via -Wl,-soname,libspread.so.2 in libspread/Makefile as > generated by configure. Therefore, to complete a 64-bit build using > the stock gcc and Solaris linker, change -soname to -h (which is > will also work with the GNU linker) in configure, yielding the > following command sequence to complete your build: > > perl -pi -e 's/-soname/-h/g' configure; > ./configure --prefix=/opt/spread-4.1.0 CC='gcc -m64' CFLAGS='-m64 -O2' LDFLAGS='-m64 -lrt'; > > daniel > > o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o o-o-o-o-o-o-o-o-o-o-o-o-o-o > s a v a r e s e > software research > http://www.savarese.com/ > > > _______________________________________________ > Spread-users mailing list > Spread-users at lists.spread.org > http://lists.spread.org/mailman/listinfo/spread-users > > >