Most webservers out there are linux. This isn't a
problem IMO.
--- Mark Wedel <[EMAIL PROTECTED]> wrote:
> Brendan Lally wrote:
>
> >> Right - I'm not sure the cost of doing it web
> server based vs independent
> >>program. For the number of crossfire servers
> we're talking about, probably
>
Brendan Lally wrote:
Right - I'm not sure the cost of doing it web server based vs independent
program. For the number of crossfire servers we're talking about, probably
not a big deal in any case - although with it being web server based, you
do have to be concerned with things like file lock
On 6/16/05, Brendan Lally <[EMAIL PROTECTED]> wrote:
...
> Yes, Server intercommunication could then be done at the proper level, so that
> shouts could go between servers.
>
> Then tell would act in a similar way to jabber.
> eg,
>
> tell [EMAIL PROTECTED]
> or
> tell [EMAIL PROTECTED]
>
> with
On Thursday 16 June 2005 06:02, Mark Wedel wrote:
> Since server updates may be sporadic, presumably the metaservers won't
> drop the listing for a server until some amount of time passes (30 minutes
> or something). Note also that the current metaserver tracks when it last
> got an update from
Brendan Lally wrote:
On Friday 10 June 2005 06:27, Mark Wedel wrote:
A few more notes/thoughts:
For the server, switching to tcp is perhaps a good thing. What I'd
actually think is the best thing is there to be a small helper program that
the server executes, and then talks to that helper p
On Friday 10 June 2005 06:27, Mark Wedel wrote:
> A few more notes/thoughts:
>
> For the server, switching to tcp is perhaps a good thing. What I'd
> actually think is the best thing is there to be a small helper program that
> the server executes, and then talks to that helper program then a
A few more notes/thoughts:
For the server, switching to tcp is perhaps a good thing. What I'd actually
think is the best thing is there to be a small helper program that the server
executes, and then talks to that helper program then a named socket (or perhaps
just a pipe). The server cou
>>> [EMAIL PROTECTED] 06/09/05 06:08 AM >>>
> seems to me that making the CMS ip secret is just security through
> obscurity.
> Once someone discovers that IP through whatever method, you lose that
> benefit
> - this means the CMS has to be secure on its own.
Yeah, what I have had in mind a
>>> [EMAIL PROTECTED] 06/09/05 21:07 PM >>>
> Obsurity is just one layer of security. It is used by
> IRC servers rather sucessfully for their hub server.
> http://cavetroll.uwcs.co.uk/
> http://cavetroll.uwcs.co.uk/metaserver/
er, that one doesn't actually work properly, (an issue with perl modu
Obsurity is just one layer of security. It is used by
IRC servers rather sucessfully for their hub server.
http://cavetroll.uwcs.co.uk/
http://cavetroll.uwcs.co.uk/metaserver/
--- Mark Wedel <[EMAIL PROTECTED]> wrote:
> Mitch Obrian wrote:
> > Cave's php metaservers are great. The sms's are
> se
I'm not sure if its been suggested, and I'm probably missing some part
of the discussion. I heard somewhere on the list that the metaserver
required the use of udp, which is easily spoofable. By that I mean that
no connection handshake required to start data transfer, and most isps
don't seem
Mitch Obrian wrote:
Cave's php metaservers are great. The sms's are sent
the data by the servers. They then send the info to
the cms which sends the info to the other sms's. This
way (since the sms's are trusted) the cms is unDoSable
as it's ip is unknown except for the trusted sms.
Since cave's
Andrew Fuchs wrote:
I think that some of the "client metaservers" should be able to work
directly with the servers, these metaservers would have to be more
trusted than the normal ones though.
Something that could be done well with the way that cavehippo's php one
is set up with 'active' and
On Thu, 2 Jun 2005, Mark Wedel wrote:
1) Has someone agreed to run the metametaserver? What about the slave
metaservers? While all this looks nice, if you don't have people willing to
run it/take care of it, it is all pretty pointless. For the metametaserver,
I'm thinking more of the Tann
I think that some of the "client metaservers" should be able to work
directly with the servers, these metaservers would have to be more
trusted than the normal ones though.
--
--
Andrew Fuchs
___
crossfire mailing list
crossfire@metalforge.org
http://m
I could run the meta-metaserver if you wanted...
--- Mark Wedel <[EMAIL PROTECTED]> wrote:
> tchize wrote:
> > Le Jeudi 2 Juin 2005 09:20, Mark Wedel a écrit :
>
> >>1) Has someone agreed to run the metametaserver?
> What about the slave
> >>metaservers? While all this looks nice, if you
> don
Cave's php metaservers are great. The sms's are sent
the data by the servers. They then send the info to
the cms which sends the info to the other sms's. This
way (since the sms's are trusted) the cms is unDoSable
as it's ip is unknown except for the trusted sms.
Since cave's metaservers are writte
As asked, here is my thought on this.
To make typing this easier, CMS = chief (core) metaserver. SMS = slave
metaserver
There is one CMS. All crossfire servers that want to be listed in metaserver
output send there data to this server (exactly how - udp/tcp, and what to send
is an open i
tchize wrote:
Le Jeudi 2 Juin 2005 09:20, Mark Wedel a écrit :
1) Has someone agreed to run the metametaserver? What about the slave
metaservers? While all this looks nice, if you don't have people willing
to run it/take care of it, it is all pretty pointless. For the
metametaserver, I'm th
I can also host a slave metaserver.
--- Brendan Lally <[EMAIL PROTECTED]> wrote:
> >>> [EMAIL PROTECTED] 06/02/05 08:23 AM >>>
>
> > 1) Has someone agreed to run the metametaserver?
> What about the slave
> > metaservers?
>
> I can host one, maybe two, but this assumes the use
> of HTTP.
>
>
>>> [EMAIL PROTECTED] 06/02/05 08:23 AM >>>
> 1) Has someone agreed to run the metametaserver? What about the slave
> metaservers?
I can host one, maybe two, but this assumes the use of HTTP.
> 4) Has anyone considered the approach where all the servers talk to the
> metametaserver (lets call
21 matches
Mail list logo
