On Tue, 4 Sep 2007, Peter Eisch wrote:
Would it be possible to implement ->id as a hook? The actual key could then
be left to the creativity of the user. The plugin could then implement the
other hooks and tune the id as necessary (connect, mail, queue, etc.).
Yes, it's possible to do it tha
On 9/4/07 1:14 PM, "Matt Sergeant" <[EMAIL PROTECTED]> wrote:
> On 4-Sep-07, at 12:43 PM, Peter J. Holzer wrote:
>
>> I was playing around a bit on the weekend, yes. Since neither Matt nor
>> Ask have cried out in horror on what I did,
>
> FWIW I didn't object simply because it seems so pointles
On Sep 4, 2007, at 9:43, Peter J. Holzer wrote:
I was playing around a bit on the weekend, yes. Since neither Matt nor
Ask have cried out in horror on what I did, I guess it's time to
present
that to a wider audience:
I just got back from vacation and is hopelessly behind on reading up
o
On 4-Sep-07, at 12:43 PM, Peter J. Holzer wrote:
I was playing around a bit on the weekend, yes. Since neither Matt nor
Ask have cried out in horror on what I did,
FWIW I didn't object simply because it seems so pointless with
everyone having such conflicting ideas about what this should all
On 2007-09-04 07:59:15 -0700, JT Moree wrote:
> > $instance_id# could be opaque or structured to include server name
> > # or IP, PID, etc.
> > $instance_id.$connection_id # identifies a connection handled
> > # by this instance
> > $insta
> $instance_id # could be opaque or structured to include server name
> # or IP, PID, etc.
> $instance_id.$connection_id # identifies a connection handled
> # by this instance
> $instance_id.$connection_id.$transaction_id # identifies a
>
On Sun, 2007-09-02 at 17:52 -0500, David Nicol wrote:
> How does qmail do it?
Uses the inode number ... doesn't work for qpsmtpd ... and it's crap for
logging (see my comment earlier in the thread) since the inodes get
recycled.
--
--gh
How does qmail do it?
On Sat, 2007-09-01 at 10:08 +0200, Peter J. Holzer wrote:
> > > Better encode it binary. E.g. for IPv4:
> >
> > And better get the number of bits correct. An IP address is a 32
> bit
> > integer, not 15 characters.
>
> You've snipped the context. JT was calling the
> Qpsmtpd::Connection::local_i
On 2007-08-29 19:15:37 -0400, Guy Hulbert wrote:
> On Thu, 2007-08-30 at 00:49 +0200, Michael Holzt wrote:
> > > or even
> > > 10 + 1 + 16 + 1 + 39 + 1 + 5 + 1 + 39 + 1 + 5 = 119 characters
> >
> > Better encode it binary. E.g. for IPv4:
>
> And better get the number of bits correct. An IP a
On 2007-08-31 11:28:55 -0400, m. allan noah wrote:
> On 8/31/07, Peter J. Holzer <[EMAIL PROTECTED]> wrote:
> > On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
> > > However, there is still an issue with Peter's proposed "zero out remote
> > > address components" proposal - prior to accept(), qp
On 2007-08-31 13:44:44 -0400, Charlie Brady wrote:
>
> On Fri, 31 Aug 2007, Peter J. Holzer wrote:
> >On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
> >127.0.0.1 is a problem even after establishing the connection: With
> >"normal" routing arrangements the remote IP address will be 127.0.0.1,
On Fri, 31 Aug 2007, Peter J. Holzer wrote:
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
However, there is still an issue with Peter's proposed "zero out remote
address components" proposal - prior to accept(), qpstmpd-forkserver may
have multiple listening sockets. Some of those socket
On 8/31/07, Peter J. Holzer <[EMAIL PROTECTED]> wrote:
> On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
> >
> > On Fri, 31 Aug 2007, Michael Holzt wrote:
> >
> > >>You can't have multiple processes bound to the same
> > >>local_IP/local_port,
> > >
> > >Of course you can.
> > >
> > >bind -> lis
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
>
> On Fri, 31 Aug 2007, Michael Holzt wrote:
>
> >>You can't have multiple processes bound to the same
> >>local_IP/local_port,
> >
> >Of course you can.
> >
> >bind -> listen -> fork
>
> Yes, brain fart at my end. s/$/ except by inheritance po
On Fri, 31 Aug 2007, Michael Holzt wrote:
You can't have multiple processes bound to the same
local_IP/local_port,
Of course you can.
bind -> listen -> fork
Yes, brain fart at my end. s/$/ except by inheritance post-fork/.
If we stop listening post-fork (as qpsmtpd-forkserver does) then t
> You can't have multiple processes bound to the same
> local_IP/local_port,
Of course you can.
bind -> listen -> fork
Regards
Michael
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
On 2007-08-30 21:12:15 -0400, Charlie Brady wrote:
> On Thu, 30 Aug 2007, Peter J. Holzer wrote:
> >On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
> >>A four-tuple identifying the TCP connection also identifies the server.
> >
> >Right. And the tuple must not be reused for some time (2*MSL or 4
On Thu, 30 Aug 2007, Peter J. Holzer wrote:
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a hig
On 2007-08-30 07:07:51 -0400, Guy Hulbert wrote:
> On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
> > On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
> > Here are some (measured) resolutions of gettimeofday on various systems:
> >
> > Linux/i386: 1 ms
> > Linux/SPARC: 2 ms
> >
On 30-Aug-07, at 4:22 PM, Peter J. Holzer wrote:
I think it should be possible to derive the transaction id from the
connection id, but I see no way to get from a transaction object to
the
underlying connection object. Am I blind?
No, there isn't. In an earlier patch I passed in the connect
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
> A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a high resolution timer.
However, what if there is
On 30-Aug-07, at 2:52 PM, Guy Hulbert wrote:
Actually, I think the right answer is just a sequence generator (mod
1). That guarantees different consecutive results.
I think so too. In my testing perl only switches to floating point at
or around 2**50 on 32 bit platforms, which should al
On 2007-08-30 13:55:08 -0400, Guy Hulbert wrote:
> On Thu, 2007-08-30 at 13:53 -0400, Guy Hulbert wrote:
> > On Fri, 2007-08-31 at 00:59 +0800, Ask Bjørn Hansen wrote:
> > > Woah - bikeshedding galore!
> > >
> > > I just got my email downloaded to my mac (I'm traveling) and Mail.app
> > > says t
Ask asked us to stop ... but what the heck ;-).
Perhaps we should drop the list after this one though.
On Thu, 2007-08-30 at 14:19 -0400, Matt Sergeant wrote:
> On 30-Aug-07, at 10:57 AM, Guy Hulbert wrote:
>
> > Nope. I reject this. The design ASSUMES that the clock has
> > "sufficient
> >
On 30-Aug-07, at 10:57 AM, Guy Hulbert wrote:
Nope. I reject this. The design ASSUMES that the clock has
"sufficient
resolution". It is the implementation which chooses Time::HiRes.
Fine, so on Alpha, you have a qpsmtpd installation that is using
async and doing more than 1000 mails/sec
On Thu, 2007-08-30 at 13:53 -0400, Guy Hulbert wrote:
> On Fri, 2007-08-31 at 00:59 +0800, Ask Bjørn Hansen wrote:
> > Woah - bikeshedding galore!
> >
> > I just got my email downloaded to my mac (I'm traveling) and Mail.app
> > says there are 61 mails in this thread (plus those I deleted
> >
On Fri, 2007-08-31 at 00:59 +0800, Ask Bjørn Hansen wrote:
> Woah - bikeshedding galore!
>
> I just got my email downloaded to my mac (I'm traveling) and Mail.app
> says there are 61 mails in this thread (plus those I deleted
> earlier!?!).
>
> Enough already.
There might have been a little
Guy Hulbert wrote:
> me = linux1
> -> linux1__
>
> me = linux2.example.com
> -> linux2.e
>
> If you run two instances you can call them 'thing1' and 'thing2'.
>
I'd rather not.
--
JT Moree
Woah - bikeshedding galore!
I just got my email downloaded to my mac (I'm traveling) and Mail.app
says there are 61 mails in this thread (plus those I deleted
earlier!?!).
Enough already.
If anyone has a serious realistic concern with what Matt did, please
provide a perl implementation o
On Aug 26, 2007, at 10:02, Matt Sergeant wrote:
On 25-Aug-07, at 8:37 PM, Guy Hulbert wrote:
The mod_uniqueid module in apache has quite a reasonable
implementation.
There is a perl implementation on CPAN (in my directory).
I'm assuming Ask is referring to Apache::Usertra
On Thu, 2007-08-30 at 10:30 -0400, Matt Sergeant wrote:
> On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
>
> > On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
[snip]
> > GH> the discussion *documents* the implementation.
> >
> > I meant undocumented as in it in Transaction.pm currentl
On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH> wtf does this mean - the *purpose* of the discussion is to *fix* a
GH> *unique* transaction ID when the discussion is over it is
*fixed* and
GH> the discussion *documents* the imple
On Thu, 2007-08-30 at 16:07 +0200, Tony L. Svanstrom wrote:
> To qpsmtpd the hostname isn't as unique as the IPs + port used by it
> is.
But for qpsmptd the "hostname" is configurable ( config('me') ). As
long as a hash is not used (see my follow-up to Matt) and the function
used is documented,
On Thu, 2007-08-30 at 10:01 -0400, Matt Sergeant wrote:
> > That is not true. Random numbers do not give unique results.
>
> True enough. But I'm going out on a limb to assume that it's good
> enough for logging. It's not a security feature.
But this (by design[*]) doesn't meet the requirement
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH> wtf does this mean - the *purpose* of the discussion is to *fix* a
GH> *unique* transaction ID when the discussion is over it is *fixed* and
GH> the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.
On 30-Aug-07, at 9:34 AM, Guy Hulbert wrote:
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
The part of the unique ID meant to identify the server is now
Is this "unique ID" the "transaction ID" we've been discussing.
Yes.
Has someone already implemented it in svn - I thought it
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
> > The part of the unique ID meant to identify the server is now
Is this "unique ID" the "transaction ID" we've been discussing.
Has someone already implemented it in svn - I thought it was a new
proposal (I'm just a bit confused here) ?
On 30-Aug-07, at 4:45 AM, Tony L. Svanstrom wrote:
True, but the code makes both the security guy and the programmer
in me
twitch...
Well, don't think of it for security then :-)
The part of the unique ID meant to identify the server is now
focusing on the
OS/computer instead of the in
On Thu, 2007-08-30 at 10:45 +0200, Tony L. Svanstrom wrote:
> > > Would this be a bad time to mention that people might get the idea that
> > > they want to run two different setups of qpsmtpd on the same server?
> >
> > No that's fine. PID is still in there taking care of that.
>
> True, but t
On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
> On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
[snip]
> > Just assume that time() can have the granularity of the CPU instruction
> > counter[1].
>
> It could (if your perl implementation uses 128 bit long doubles), but it
Or you could
On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
> On 29-Aug-07, at 6:38 PM, Tony L. Svanstrom wrote:
>
> > On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
> >
> > MS> I've added in a basic hashed version of hostname now.
> >
> > Would this be a bad time to mention that people
On 2007-08-30 10:08:36 +0200, Peter J. Holzer wrote:
> Here are some (measured) resolutions of gettimeofday on various systems:
>
> Linux/i386: 1 ms
> Linux/SPARC: 2 ms
> HP-UX/PA-RISC: 2 ms
> Linux/Alpha: 976 ms (1024 Hz)
>
> Ok, so the Alpha is obsolete, and Sun and HP hardware see
On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
> On Wed, 2007-08-29 at 18:03 -0400, Charlie Brady wrote:
> > That is just asserting that no single process could receive two
> > connections in the same tick of time() (because if it could, it's
> > trivial
>
> Just assume that time() can have th
On 29-Aug-07, at 7:02 PM, m. allan noah wrote:
On 8/29/07, Matt Sergeant <[EMAIL PROTECTED]> wrote:
On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
"Except with multiple CPUs" is a big problem. OTOH, as has been
mentioned multiple times, a four-tuple identifying the TCP
connection plus a times
On 29-Aug-07, at 6:38 PM, Tony L. Svanstrom wrote:
On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
MS> I've added in a basic hashed version of hostname now.
Would this be a bad time to mention that people might get the idea
that they
want to run two different setups of qpsmtpd on
On 29-Aug-07, at 6:03 PM, Charlie Brady wrote:
That is just asserting that no single process could receive two
connections in the same tick of time() (because if it could, it's
trivial to arrange for them to have the same remote port). I can
conceive of that happening, so we should do bette
On Wed, 2007-08-29 at 19:15 -0400, Guy Hulbert wrote:
[snip]
> And better get the number of bits correct. An IP address is a 32 bit
> integer, not 15 characters. Although perl converts scalars on-demand,
I should have said 'unsigned'.
[snip]
> IPv-agnostic. At this point we are at 128 bits (8
On Thu, 2007-08-30 at 00:49 +0200, Michael Holzt wrote:
> > or even
> > 10 + 1 + 16 + 1 + 39 + 1 + 5 + 1 + 39 + 1 + 5 = 119 characters
>
> Better encode it binary. E.g. for IPv4:
And better get the number of bits correct. An IP address is a 32 bit
integer, not 15 characters. Although perl c
On 8/29/07, Matt Sergeant <[EMAIL PROTECTED]> wrote:
> On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
>
> > "Except with multiple CPUs" is a big problem. OTOH, as has been
> > mentioned multiple times, a four-tuple identifying the TCP
> > connection plus a timestamp will be satisfactory with any nu
> > my $lip = $conn->local_ip();
> up to 15 characters (39 with IPv6)
> > my $rip = $conn->remote_ip();
> up to 15 characters (39 with IPv6)
> > my $rport = $conn->remote_port || "0";
> up to 5 characters
> > my $lport = $conn->local_port || "0";
> up to 5 characters
> > my $start =
Peter.
I think it might help if you were to just rewrite "the requirements"
properly. I don't have strong opinions on what the solution should be
nor what the requirements should be. As long as the total number is
small and they are written concisely they will either converge or, if
necessary, w
On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
MS> I've added in a basic hashed version of hostname now.
Would this be a bad time to mention that people might get the idea that they
want to run two different setups of qpsmtpd on the same server? Like one for
incoming e-mails and one
On Wed, 2007-08-29 at 18:03 -0400, Charlie Brady wrote:
> That is just asserting that no single process could receive two
> connections in the same tick of time() (because if it could, it's
> trivial
Just assume that time() can have the granularity of the CPU instruction
counter[1]. However, wi
On Wed, 29 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 11:04 PM, Charlie Brady wrote:
> Err, actually I had a brain fart. It should be remote_port.
No, it should be remote_IP.remote_port.local_port and should include a
transaction_within_connection count. I don't think that pid adds any
On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
"Except with multiple CPUs" is a big problem. OTOH, as has been
mentioned multiple times, a four-tuple identifying the TCP
connection plus a timestamp will be satisfactory with any number of
CPUs, and with very fast networks.
pid entirely sat
On Wed, 29 Aug 2007, David Sparks wrote:
A UUID is preferable to the other solutions because you can condense it
down to 128 bits of binary data ... and put it in a database. :)
A UUID, OTOH, only makes collisions unlikely, not impossible, and also
uses up entropy, which may be a relatively
On 29-Aug-07, at 1:07 PM, Guy Hulbert wrote:
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
Then forget about the word "security", and let's just say that
people might
want to have unique IDs that'll be unique even when they've got
more than one
server and centralized/aggrega
On Wed, 29 Aug 2007, Guy Hulbert wrote:
1. A unique ID per message (on one server).
2. Ability to distinguish per recipient.
3. Ability to identify the server.
A sequence solves (1) except for simultaneous processing of
incoming messages via:
a) async
b
On 2007-08-29 09:08:56 -0700, JT Moree wrote:
> > If you leave out any of the local info, an installation with two
> > servers with un-synced times could still gen the same id. if you add
> > it, then the only way you could have a collision is if your time is
> > not granular enough or gets set bac
On 2007-08-29 13:07:06 -0400, Guy Hulbert wrote:
> On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
> > On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
> >
> > GH> Why is there all this confusion about "security" ? The goal is to have
> > GH> a unique MessageID for logs ...
> >
On Wed, 2007-08-29 at 11:16 -0700, JT Moree wrote:
> Guy Hulbert wrote:
> > There have been several adequate suggestions. This is only a problem if
> > it goes into the qpsmtpd core since some of the suggestions are reported
> > to be in use already.
> how is this a problem. those uses should sti
Tony L. Svanstrom wrote:
Then forget about the word "security", and let's just say that people might
want to have unique IDs that'll be unique even when they've got more than one
server and centralized/aggregated logging... But we're not even there right
now, "we" are still stuck on how to mak
Guy Hulbert wrote:
> There have been several adequate suggestions. This is only a problem if
> it goes into the qpsmtpd core since some of the suggestions are reported
> to be in use already.
how is this a problem. those uses should still work even if we start
with the same variable because they
On Wed, 2007-08-29 at 10:14 -0700, David Sparks wrote:
> A UUID is preferable to the other solutions because you can condense it
> down to 128 bits of binary data ... and put it in a database. :)
HiRes::Timer is 64 bits ... leaving 64 bits for the server tag.
>
> The other solutions are not as d
A UUID is preferable to the other solutions because you can condense it
down to 128 bits of binary data ... and put it in a database. :)
The other solutions are not as database friendly. It seems to me if
we're trying to solve the problem of guaranteeing unique transaction ids
for extremely high
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
> On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
>
> GH> Why is there all this confusion about "security" ? The goal is to have
> GH> a unique MessageID for logs ...
>
> Then forget about the word "security", and let's just sa
On Wed, 2007-08-29 at 12:23 -0400, m. allan noah wrote:
> On 8/29/07, Guy Hulbert <[EMAIL PROTECTED]> wrote:
> > > if you want to be paranoid, you have to have all 4 data points from
> >
> > Why is there all this confusion about "security" ? The goal is to have
> > a unique MessageID for logs ...
On 8/29/07, Guy Hulbert <[EMAIL PROTECTED]> wrote:
> > if you want to be paranoid, you have to have all 4 data points from
>
> Why is there all this confusion about "security" ? The goal is to have
> a unique MessageID for logs ...
i never said security. i said paranoid, specifically about collis
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH> Why is there all this confusion about "security" ? The goal is to have
GH> a unique MessageID for logs ...
Then forget about the word "security", and let's just say that people might
want to have unique IDs that'll be unique even when
> If you leave out any of the local info, an installation with two
> servers with un-synced times could still gen the same id. if you add
> it, then the only way you could have a collision is if your time is
> not granular enough or gets set back.
I'm ok with that
Using HiRes::Time
my $lip = $c
> > Isn't localport always 25?
> the most time: yes.
> But it can also be 465
Also port 587 (message submission as per RFC2476).
Regards
Michael
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
On Wed, 2007-08-29 at 11:53 -0400, m. allan noah wrote:
> On 8/29/07, JT Moree <[EMAIL PROTECTED]> wrote:
> > Given that we are still disagreeing on what is the best way to do it;
> > Can we use all information used so far to get the most unique possible
> > for now? Even if it's not perfect, it's
On 8/29/07, JT Moree <[EMAIL PROTECTED]> wrote:
> Given that we are still disagreeing on what is the best way to do it;
> Can we use all information used so far to get the most unique possible
> for now? Even if it's not perfect, it's a start. Even if some of the
> information seems extraneous to
Given that we are still disagreeing on what is the best way to do it;
Can we use all information used so far to get the most unique possible
for now? Even if it's not perfect, it's a start. Even if some of the
information seems extraneous to some people (and may be) it's still
better than nothing
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH> On Wed, 2007-08-29 at 16:53 +0200, Tony L. Svanstrom wrote:
GH> > (Only reason I gave this some thought was because I few days ago wanted
unique
GH> > IDs traceable to a single server, without having to use statically
assigned
GH>
GH
On Wed, 2007-08-29 at 16:53 +0200, Tony L. Svanstrom wrote:
> (Only reason I gave this some thought was because I few days ago wanted
> unique
> IDs traceable to a single server, without having to use statically assigned
Look at UUID. That is what it is for.
> identifiers. The purely securit
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH> On Tue, 2007-08-28 at 23:04 -0400, Charlie Brady wrote:
GH> > > On 28-Aug-07, at 3:51 PM, JT Moree wrote:
GH> > >>> hires_time.pid.local_port
GH> > ...
GH> > >>my $conn = $args{connection};
GH> > >>my $ip = $conn->local_port || "0"
Charlie Brady wrote:
On Tue, 28 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
hires_time.pid.local_port
...
my $conn = $args{connection};
my $ip = $conn->local_port || "0";
my $start = time;
my $id = "$start.$$.$ip";
Some people have suggested adding
Chris Garrigues wrote:
>> From: Charlie Brady <[EMAIL PROTECTED]>
>> Date: Tue, 28 Aug 2007 23:04:56 -0400 (EDT)
>>
>> No, it should be remote_IP.remote_port.local_port and should include a
>> transaction_within_connection count. I don't think that pid adds anything.
>>
>
> Isn't localport
> From: Charlie Brady <[EMAIL PROTECTED]>
> Date: Tue, 28 Aug 2007 23:04:56 -0400 (EDT)
>
> No, it should be remote_IP.remote_port.local_port and should include a
> transaction_within_connection count. I don't think that pid adds anything.
Isn't localport always 25?
Chris
--
Chris Garrigues
On 28-Aug-07, at 11:04 PM, Charlie Brady wrote:
Err, actually I had a brain fart. It should be remote_port.
No, it should be remote_IP.remote_port.local_port and should
include a transaction_within_connection count. I don't think that
pid adds anything.
Please try any way you can to get
On Tue, 2007-08-28 at 23:04 -0400, Charlie Brady wrote:
> > On 28-Aug-07, at 3:51 PM, JT Moree wrote:
> >>> hires_time.pid.local_port
> ...
> >>my $conn = $args{connection};
> >>my $ip = $conn->local_port || "0";
> >>my $start = time;
> >>my $id = "$start.$$.$ip";
> >>
> >> Some pe
On Tue, 28 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
hires_time.pid.local_port
...
my $conn = $args{connection};
my $ip = $conn->local_port || "0";
my $start = time;
my $id = "$start.$$.$ip";
Some people have suggested adding the remote IP address
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
I found the svn web interface:
# generate id
my $conn = $args{connection};
my $ip = $conn->local_port || "0";
my $start = time;
my $id = "$start.$$.$ip";
Some people have suggested adding the remote IP address. I'm curious
why use local port
Matt Sergeant wrote:
> On 28-Aug-07, at 3:12 PM, JT Moree wrote:
>
>> Matt Sergeant wrote:
>>> I've checked in $transaction->id support now. Please let me know if you
>>> think it's OK.
>>
>> which method did you use?
>
> hires_time.pid.local_port
I found the svn web interface:
# generate id
On 28-Aug-07, at 3:12 PM, JT Moree wrote:
Matt Sergeant wrote:
I've checked in $transaction->id support now. Please let me know
if you
think it's OK.
which method did you use?
hires_time.pid.local_port
Matt.
Matt Sergeant wrote:
> I've checked in $transaction->id support now. Please let me know if you
> think it's OK.
which method did you use?
--
JT Moree
I've checked in $transaction->id support now. Please let me know if
you think it's OK.
Matt.
> remoteIP + remotePort + fineGrainedTime is what we use in-house for
> some high-speed http logging that needs a unique handle. it works just
> fine with a fair number of concurrent clients behind a nat or proxy.
> but, my installation is not massive :)
Add PID and a per-process message-counter a
Why not use something like Data::UUID?
http://search.cpan.org/~rjbs/Data-UUID-1.148/UUID.pm
There is reads:
"It provides reasonably efficient and reliable framework for generating
UUIDs and supports fairly high allocation rates -- 10 million per second
per machine -- and therefore is suitable f
On 8/28/07, JT Moree <[EMAIL PROTECTED]> wrote:
> James W. Abendschan wrote:
> > The check_earlytalker plugin ensures at least a one
> > second pause in every SMTP session, so time() + peer IP
> > + peer port will be far more unique than a random number :-)
>
> This has been suggested a few times b
James W. Abendschan wrote:
> The check_earlytalker plugin ensures at least a one
> second pause in every SMTP session, so time() + peer IP
> + peer port will be far more unique than a random number :-)
This has been suggested a few times but I'd rather not have to have ids
for the system depend on
On Sat, 2007-08-25 at 22:02 -0400, Matt Sergeant wrote:
> > Here is ask's directory:
> >
> > http://cpan.org/modules/by-authors/id/ABH/?M=A
> >
> > I don't see it ...
>
> I'm assuming Ask is referring to Apache::Usertrack, which does this:
>
>my $remotename = $r->connection->remote_host || $r
On 25-Aug-07, at 8:37 PM, Guy Hulbert wrote:
The mod_uniqueid module in apache has quite a reasonable
implementation.
There is a perl implementation on CPAN (in my directory).
- ask
Here is ask's directory:
http://cpan.org/modules/by-authors/id/ABH/?M=A
I don't
On Sat, 2007-08-25 at 13:24 -0700, JT Moree wrote:
> email message attachment (Re: Transaction ID suggestions)
> On Sat, 2007-08-25 at 13:24 -0700, JT Moree wrote:
In the attachment.
On Fri, 24 Aug 2007 11:52:07 -0700 "JT Moree" <[EMAIL PROTECTED]>
wrote:
On Sat, 2007-08-25 at 14:55 -0700, James W. Abendschan wrote:
> The check_earlytalker plugin ensures at least a one
> second pause in every SMTP session, so time() + peer IP
> + peer port will be far more unique than a random number :-)
IF you use check_earlytalker configured as you describe then
On Fri, 24 Aug 2007, Guy Hulbert wrote:
> > fqdn + time + peer TCP port will be pretty unique, regardless of
>
> fqdn is the trivial part
>
> rand will be "pretty unique" ...
Initial connection time, peer IP, and peer port will only
repeat if the connection is torn down and restablished with
the
--
JT Moree
--- Begin Message ---
On Fri, 24 Aug 2007 11:52:07 -0700 "JT Moree" <[EMAIL PROTECTED]>
wrote:
>These are the approaches suggested so far. I added the last one as a
>combination of the others. Can we see a show of hands for the one
>people like the best?
The mod_uniqueid module i
David Sparks wrote:
>>> = sprintf("%.6f", time()) .".". $self->qp->config("me") . \
>>> sprintf("%08X", rand(2**32 - 1)); #how expensive is this?
> The big advantage to using time() + id as the least significant digit is
> that you can put the id in a db server as a double or unixtime which
> c
1 - 100 of 115 matches
Mail list logo
