About Resource id's
DiAvOl
I am using a simple php server that I wrote and have some questions
related to the resource id's. When a new client connects to the server
or the server opens a file the Resource id number increases normally,
but when the server closes the socket and the file and then a new
client connects or file opens, the Resource id still increases without
reseting to the previous closed id's.
For example:
Client connects to the server...accept();
Client fd: Resource id #1
client quits.... fclose/socket_close
Client connects to the server...accept();
Client fd: Resource id #2
client quits.... fclose/socket_close
...
...
...
Client connects to the server...accept();
Client fd: Resource id #12456
Shouldn't the resource id reset to #1 when the second client
connected ? Can this behaviour cause problems to the server ?
I wrote a simple socket server and client to demonstrate this:
server:
----------
<?php
set_time_limit(0);
$socket = stream_socket_server("tcp://0.0.0.0:6000", $errno, $errstr);
if (!$socket) {
echo "$errstr ($errno)<br />\n";
} else {
while ($conn = stream_socket_accept($socket)) {
testme();
testme();
testme();
print("Client fd: ".$conn." \n");
fclose($conn);
echo '$socket is resource = ' . (is_resource($conn) ? 'true':
'false')."\n";
}
fclose($socket);
}
function testme() {
$fp = fopen('testfdss','a');
fclose($fp);
echo '$file_pointer is resource = ' . (is_resource($p) ? 'true':
'false')."\n";
}
?>
client:
---------
<?php
set_time_limit(0);
while(true) {
$fp = fsockopen('127.0.0.1',6000,$errno,$errstr,(float) 1);
if (!$fp) {
print("error()\n");
}
fclose($fp);
}
?>
Thanks for your help and sorry for my (bad) english
Jerry Stuckle
> Hello,
>
> I am using a simple php server that I wrote and have some questions
> related to the resource id's. When a new client connects to the server
> or the server opens a file the Resource id number increases normally,
> but when the server closes the socket and the file and then a new
> client connects or file opens, the Resource id still increases without
> reseting to the previous closed id's.
>
> For example:
>
> Client connects to the server...accept();
> Client fd: Resource id #1
> client quits.... fclose/socket_close
> Client connects to the server...accept();
> Client fd: Resource id #2
> client quits.... fclose/socket_close
> ...
> ...
> ...
> Client connects to the server...accept();
> Client fd: Resource id #12456
>
> Shouldn't the resource id reset to #1 when the second client
> connected ? Can this behaviour cause problems to the server ?
>
Why should it? The actual value is immaterial. It is only a unique id
used to identify a reference.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
DiAvOl
> used to identify a reference.
What if the above code example runs forever ? The resource id will be
increasing forever and overflow sometime...
Michael Fesser
It's handled internally by the interpreter. Don't worry about it.
The engine is smart enough to keep an eye on such things.
Micha
Jerry Stuckle
Then you'll need an infinite number.
But nothing runs forever.
What is your real PROBLEM? Or are you just looking for one?
DiAvOl
> ==================
I am running a stream_select server which actually runs forever
(daemon mode) and I worried because the Resource id number is around
29000 so far and I don't know what happens if that number increases
forever. Another reason for asking is because maybe someone have read
the source code and knows better about it.
Thanks
Jerry Stuckle
So? Do you think it's going to run for years without a server reboot?
NOTHING runs forever!
How long has it been running to get to 29K?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Michael Fesser
>DiAvOl wrote:
>
>> I am running a stream_select server which actually runs forever
>> (daemon mode) and I worried because the Resource id number is around
>> 29000 so far and I don't know what happens if that number increases
>> forever. Another reason for asking is because maybe someone have read
>> the source code and knows better about it.
>
>So? Do you think it's going to run for years without a server reboot?
Possible.
>NOTHING runs forever!
Just think of older Windows versions - without reboot they crashed after
49 days because of an internal integer overflow. But I really think that
the PHP interpreter is capable of handling such things and clever enough
to re-use free resource IDs if necessary.
>How long has it been running to get to 29K?
I was about to ask a similar question. And even if PHP would just
increase the number - what about the "natural" limits? A 32bit signed
integer is more than 2*10^9, unsigned it's twice as big (I simply assume
PHP doesn't use just 16bit words ...)
Micha
Jerry Stuckle
> .oO(Jerry Stuckle)
>
>> DiAvOl wrote:
>>
>>> I am running a stream_select server which actually runs forever
>>> (daemon mode) and I worried because the Resource id number is around
>>> 29000 so far and I don't know what happens if that number increases
>>> forever. Another reason for asking is because maybe someone have read
>>> the source code and knows better about it.
>> So? Do you think it's going to run for years without a server reboot?
>
> Possible.
>
No, Micha, it isn't in the real world. But maybe it is in your fantasy
land.
Or are you just trolling again? I suspect that's the case.
>> NOTHING runs forever!
>
> Just think of older Windows versions - without reboot they crashed after
> 49 days because of an internal integer overflow. But I really think that
> the PHP interpreter is capable of handling such things and clever enough
> to re-use free resource IDs if necessary.
>
So what if Windows crashed after 49 days? And do you KNOW the PHP
interpreter can handle it? Can you point to the code? Or are you just
guessing - as usual?
>> How long has it been running to get to 29K?
>
> I was about to ask a similar question. And even if PHP would just
> increase the number - what about the "natural" limits? A 32bit signed
> integer is more than 2*10^9, unsigned it's twice as big (I simply assume
> PHP doesn't use just 16bit words ...)
>
> Micha
>
It was a rhetorical question, Micha. And instead of guessing, why don't
you find out? It's not that hard to prove.
Michael Fesser
>Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> DiAvOl wrote:
>>>
>>>> I am running a stream_select server which actually runs forever
>>>> (daemon mode) and I worried because the Resource id number is around
>>>> 29000 so far and I don't know what happens if that number increases
>>>> forever. Another reason for asking is because maybe someone have read
>>>> the source code and knows better about it.
>>> So? Do you think it's going to run for years without a server reboot?
>>
>> Possible.
>
>No, Micha, it isn't in the real world. But maybe it is in your fantasy
>land.
Servers _can_ run for years unless there's a hardware failure or a
kernel update.
>Or are you just trolling again?
I never did.
>I suspect that's the case.
Sure you do. I would be really surprised if it would be any different.
BTW: You still didn't answer my latest questions from the other threads.
>> Just think of older Windows versions - without reboot they crashed after
>> 49 days because of an internal integer overflow. But I really think that
>> the PHP interpreter is capable of handling such things and clever enough
>> to re-use free resource IDs if necessary.
>
>So what if Windows crashed after 49 days? And do you KNOW the PHP
>interpreter can handle it? Can you point to the code? Or are you just
>guessing - as usual?
I was just posting my opinion and you're offending me again without any
reason. Forgot your pills again?
>>> How long has it been running to get to 29K?
>>
>> I was about to ask a similar question. And even if PHP would just
>> increase the number - what about the "natural" limits? A 32bit signed
>> integer is more than 2*10^9, unsigned it's twice as big (I simply assume
>> PHP doesn't use just 16bit words ...)
>
>It was a rhetorical question, Micha. And instead of guessing, why don't
>you find out? It's not that hard to prove.
Why should I? I'm not the OP, I don't have that "problem". I just
pointed out that it might not be a problem at all.
But I don't expect that you understand that. Just keep on going
insulting me, if you have nothing better to do.
Micha
Jerry Stuckle
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> DiAvOl wrote:
>>>>
>>>>> I am running a stream_select server which actually runs forever
>>>>> (daemon mode) and I worried because the Resource id number is around
>>>>> 29000 so far and I don't know what happens if that number increases
>>>>> forever. Another reason for asking is because maybe someone have read
>>>>> the source code and knows better about it.
>>>> So? Do you think it's going to run for years without a server reboot?
>>> Possible.
>> No, Micha, it isn't in the real world. But maybe it is in your fantasy
>> land.
>
> Servers _can_ run for years unless there's a hardware failure or a
> kernel update.
>
That's a BIG UNLESS! How long have you had a server run?
There are always reboots for various reasons. And if the software were
perfect (which it isn't) and there were no hardware failures (which is
impossible), nothing runs FOREVER.
>> Or are you just trolling again?
>
> I never did.
>
>> I suspect that's the case.
>
> Sure you do. I would be really surprised if it would be any different.
> BTW: You still didn't answer my latest questions from the other threads.
>
Yep, I do.
And no, I tried answering your question once. Maybe if you had half a
brain (which you don't), you would find the answer yourself (which you
won't).
>>> Just think of older Windows versions - without reboot they crashed after
>>> 49 days because of an internal integer overflow. But I really think that
>>> the PHP interpreter is capable of handling such things and clever enough
>>> to re-use free resource IDs if necessary.
>> So what if Windows crashed after 49 days? And do you KNOW the PHP
>> interpreter can handle it? Can you point to the code? Or are you just
>> guessing - as usual?
>
> I was just posting my opinion and you're offending me again without any
> reason. Forgot your pills again?
>
No, you're arguing from your normal asinine position. We can only hope
that one of these days reality will find you.
>>>> How long has it been running to get to 29K?
>>> I was about to ask a similar question. And even if PHP would just
>>> increase the number - what about the "natural" limits? A 32bit signed
>>> integer is more than 2*10^9, unsigned it's twice as big (I simply assume
>>> PHP doesn't use just 16bit words ...)
>> It was a rhetorical question, Micha. And instead of guessing, why don't
>> you find out? It's not that hard to prove.
>
> Why should I? I'm not the OP, I don't have that "problem". I just
> pointed out that it might not be a problem at all.
>
You're the one who brought it up - and "assume" things. Rather than
just "assuming", get the facts.
> But I don't expect that you understand that. Just keep on going
> insulting me, if you have nothing better to do.
>
> Micha
>
Oh, I understand that. You throw out unsubstantiated assumptions and
expect everyone else to take it for the truth.
And I know you'll say that I do that, also. But such is not the case -
as I tried to tell you.
Let us know when you have some facts instead of assumptions.
DiAvOl
my servers), the program must be written as if it would, imho.
I have a Resource Id of ~29000 in about 1 day, because the php server
opens and closes files all the time - apart from the user connections
- and the id keeps growing. Anyway, I think noone can answer what
happens if the number reaches the MAX_LONG which is 32bit on my system
without looking at the source code first.
Thanks for your replies
Jerry Stuckle
OK, 29K resources in 1 day. That means it will take a little over 202
years for your program to reach the maximum size of a signed 32 bit integer.
Now - do you really think your program will be running in 200 years?
And if it is, do you really think it will be running on a 32 bit platform?
There are much more important things to worry about in your scripts.
Norman Peelman
Well,
Assuming MAX_LONG = PHP_INT_MAX (4 byte int, 32bits) = (2^32)-1 =
4294967295
(I don't know, I don't have a defined MAX_LONG) then it will work for
approximately:
Your current rate:
4294967295/29000 = 148102 days
148102/365 = 405 years
34 times your current rate:
4294967295/1000000 = 4294 days
4294/365 = 11 years
Does that help any?
Norm
Norman Peelman
The Resource ID is probably kept track of on a per-script basis and I
imagine it will roll-over when needed. See:
http://us3.php.net/manual/en/language.types.resource.php
Also, why not simply write a script to test your theory? Not sure how
long it would take... see other reply.
Norm
DiAvOl
I wrote a script but it takes too long to reach that number =). I
guess I should not worry about it, but it would be more natural (imo)
to reuse freed resource id slots.
Btw, I checked the source code for fclose but can't understand much
/* {{{ proto bool fclose(resource fp)
Close an open file pointer */
PHPAPI PHP_FUNCTION(fclose)
{
zval **arg1;
php_stream *stream;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &arg1)
== FAILURE) {
WRONG_PARAM_COUNT;
}
PHP_STREAM_TO_ZVAL(stream, arg1);
if (!stream->is_persistent) {
zend_list_delete(stream->rsrc_id);
} else {
php_stream_pclose(stream);
}
RETURN_TRUE;
}
Thanks for your help
Michael Fesser
>Michael Fesser wrote:
>
>> BTW: You still didn't answer my latest questions from the other threads.
>
>Yep, I do.
>
>And no, I tried answering your question once. Maybe if you had half a
>brain (which you don't), you would find the answer yourself (which you
>won't).
The one and only given answer from the other thread (the GG header
thingy) was wrong, which I tried to tell you and Sanders multiple times.
>You're the one who brought it up - and "assume" things. Rather than
>just "assuming", get the facts.
Assuming things is a very common things in discussions.
>Oh, I understand that. You throw out unsubstantiated assumptions and
>expect everyone else to take it for the truth.
>
>And I know you'll say that I do that, also. But such is not the case -
>as I tried to tell you.
>
>Let us know when you have some facts instead of assumptions.
I've posted facts more than once:
<news:dp9th3t2jud3aosg5...@4ax.com>
<news:rgq2i3t3998u505nj...@4ax.com>
They clearly show that you were wrong (your "assumption"!), that's why
you ignore them.
Micha
Jerry Stuckle
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>
>>> BTW: You still didn't answer my latest questions from the other threads.
>> Yep, I do.
>>
>> And no, I tried answering your question once. Maybe if you had half a
>> brain (which you don't), you would find the answer yourself (which you
>> won't).
>
> The one and only given answer from the other thread (the GG header
> thingy) was wrong, which I tried to tell you and Sanders multiple times.
>
No, it was not wrong. You just don't know what you're talking about.
>> You're the one who brought it up - and "assume" things. Rather than
>> just "assuming", get the facts.
>
> Assuming things is a very common things in discussions.
>
Like you "assume" the answer from the other thread was incorrect?
Others work on facts.
>> Oh, I understand that. You throw out unsubstantiated assumptions and
>> expect everyone else to take it for the truth.
>>
>> And I know you'll say that I do that, also. But such is not the case -
>> as I tried to tell you.
>>
>> Let us know when you have some facts instead of assumptions.
>
> I've posted facts more than once:
>
> <news:dp9th3t2jud3aosg5...@4ax.com>
> <news:rgq2i3t3998u505nj...@4ax.com>
>
> They clearly show that you were wrong (your "assumption"!), that's why
> you ignore them.
>
> Micha
>
You posted no proof at all.
Michael Fesser
>Michael Fesser wrote:
>
>> I've posted facts more than once:
>>
>> <news:dp9th3t2jud3aosg5...@4ax.com>
>> <news:rgq2i3t3998u505nj...@4ax.com>
>>
>> They clearly show that you were wrong (your "assumption"!), that's why
>> you ignore them.
>
>You posted no proof at all.
I'll give it a last try. You claimed that these two postings
<news:1192819251.4...@e34g2000pro.googlegroups.com>
<news:1192745739.4...@e34g2000pro.googlegroups.com>
were posted by the same person (your "well-known troll"), simply
because they contain the same posting-account in their headers:
Injection-Info: e34g2000pro.googlegroups.com; posting-
host=67.190.94.163;
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
I told you that you were wrong, simply because this ID also appears in
a lot of other postings from other people. Just some recent examples:
<news:1193603394....@19g2000hsx.googlegroups.com>
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 (ZeldorBlat)
<news:1193583253.2...@o38g2000hse.googlegroups.com>
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 (Kai)
<news:1193577496.1...@57g2000hsv.googlegroups.com>
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 (jemptymethod)
<news:1193407075....@o80g2000hse.googlegroups.com>
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 (Captain Paralytic)
Do I have to say more? OK, one more. Take _this_ posting (I used my
own Google account this time) and you'll find this line in the
headers:
Injection-Info: 19g2000hsx.googlegroups.com; posting-
host=88.72.15.119;
posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
(The GG server name might differ.)
If that's no proof, what then? Are we all the same person as you
claim?
And maybe you can show me two GG postings with _different_ account
IDs?
Micha
Gordon Burditt
>guess I should not worry about it, but it would be more natural (imo)
>to reuse freed resource id slots.
I disagree. It is not a good idea, or more "natural" (whatever
that means) to re-use freed resource id slots *quickly*. You don't
want old references to resources (even ones saved in databases or
web clients, which is a bad idea but people will do it anyway)
referring to valid new resources accidentally.
Consider the situation with process IDs. Some systems re-use process
IDs somewhat faster than what fits in a 16-bit number, but it is
NOT a good idea to be sure that there is almost always a PID #2,
and if there isn't one already in use, it will be the next one
assigned.
Jerry Stuckle
There's more than just what you posted which goes into reading the
headers. And if you knew how to read headers, you would know that.
Maybe I don't show all the tricks to the trolls - just some of them. Or
maybe you're just not understanding what I said.
Michael Fesser
>There's more than just what you posted which goes into reading the
>headers. And if you knew how to read headers, you would know that.
If you would know how to read headers and what they really mean, you would
have posted some more to prove your claim, not just the one that can't be
used as a proof at all. But you failed, so in fact all you posted was a
false and incompetent assumption, which you're still hanging on to.
>Maybe I don't show all the tricks to the trolls - just some of them.
You're out of arguments again. Unable to answer simple questions.
>Or
>maybe you're just not understanding what I said.
You didn't say anything useful at all, nor did you post any facts. You just
can't accept that you were proven wrong, that's the whole point. As usual.
And you should not forget who always starts the stupid flaming in such
threads. I'll give you a hint: It's not me.
EOT for me,
this is becoming quite boring
Micha