Macromedia Flash Server - Buffering problems on dialup

This is Interesting: Free IT Magazines  
Home > Archive > Macromedia Flash Server > April 2005 > Buffering problems on dialup





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Buffering problems on dialup
Stefan Richter

2005-04-07, 5:56 pm

Hi everyone,
I am currently trying to optimize recordings and playback for dialup users.
For my recording app I use a maximum recording time of 30 seconds and I set
bufferLength to 30 before a user starts recording. This works well even on
dialup (it just takes some time for the buffer to empty, (label this as
'uploading') and allows for pretty good quality recordings to be made even
on dialup.
As these are very small recordings I decided to use progressive download for
replay. Again this works well, especially for DSL/cable but not so well on
dialup...

Here's the problem:
Once a user has finished recording and hits replay I pull in the just
recorded video via progressive download. BufferTime can still be set on null
connections so what I do is I keep track of the recording time and set the
buffer to the length of the recording. In theory this should play back the
entire recording smoothly regardless of connection speed (once buffering is
finished). Am I correct so far?

I have an utility called Netlimiter which allows me to throttle my
connection speed. If I set it to dialup speed and make a recording then this
works fine. Upon replay I first see frame 1, followed by buffering (ok so
far), once the buffer is full however the video jumps several seconds into
the recording and plays from there...
If I change my connection speed to DSL then the recording plays smoothly all
the way through which proves that the rcording process went well and all
data is actually contained inside the flv.

Here are my traces for ns.time on dialup, traced every 200ms:
0 // frame 1 shows
0
0
0
0
0
0
0
0
3.893 // NetStream.Buffer.Full received, video still doesn't play
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
4.025 // video plays smooth from here
4.249
4.537
4.761
5.049
5.305
5.571 // end of the recording


Compare this to the traces on DSL speed:

0
0
0
0
0.473 // NetStream.Buffer.Full received, video plays smoothly
0.665
0.953
1.177
1.401
1.689
1.977
2.201
2.489
2.777
3.001
3.289
3.545
3.833
4.057
4.345
4.633
4.889
5.145
5.401
5.571 // end of the recording

I can't make sense of this. Can anyone else?

Stefan









=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Stefan Richter

2005-04-07, 5:56 pm

Anybody? Sorry 'bout the long winded post...

Stefan


> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Stefan Richter
> Sent: 31 March 2005 10:51
> To: 'FlashComm Mailing List'
> Subject: [FlashComm] Buffering problems on dialup
>
> Hi everyone,
> I am currently trying to optimize recordings and playback for
> dialup users.
> For my recording app I use a maximum recording time of 30
> seconds and I set bufferLength to 30 before a user starts
> recording. This works well even on dialup (it just takes some
> time for the buffer to empty, (label this as
> 'uploading') and allows for pretty good quality recordings to
> be made even on dialup.
> As these are very small recordings I decided to use
> progressive download for replay. Again this works well,
> especially for DSL/cable but not so well on dialup...
>
> Here's the problem:
> Once a user has finished recording and hits replay I pull in
> the just recorded video via progressive download. BufferTime
> can still be set on null connections so what I do is I keep
> track of the recording time and set the buffer to the length
> of the recording. In theory this should play back the entire
> recording smoothly regardless of connection speed (once
> buffering is finished). Am I correct so far?
>
> I have an utility called Netlimiter which allows me to
> throttle my connection speed. If I set it to dialup speed and
> make a recording then this works fine. Upon replay I first
> see frame 1, followed by buffering (ok so far), once the
> buffer is full however the video jumps several seconds into
> the recording and plays from there...
> If I change my connection speed to DSL then the recording
> plays smoothly all the way through which proves that the
> rcording process went well and all data is actually contained
> inside the flv.
>
> Here are my traces for ns.time on dialup, traced every 200ms:
> 0 // frame 1 shows
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 3.893 // NetStream.Buffer.Full received, video still doesn't play
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 4.025 // video plays smooth from here
> 4.249
> 4.537
> 4.761
> 5.049
> 5.305
> 5.571 // end of the recording
>
>
> Compare this to the traces on DSL speed:
>
> 0
> 0
> 0
> 0
> 0.473 // NetStream.Buffer.Full received, video plays smoothly
> 0.665
> 0.953
> 1.177
> 1.401
> 1.689
> 1.977
> 2.201
> 2.489
> 2.777
> 3.001
> 3.289
> 3.545
> 3.833
> 4.057
> 4.345
> 4.633
> 4.889
> 5.145
> 5.401
> 5.571 // end of the recording
>
> I can't make sense of this. Can anyone else?
>
> Stefan
>
>
>
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>



=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Jake Hilton

2005-04-07, 5:56 pm

Stefan,
This doesn't make much sense the way it works... I guess if you have it =
buffer 90% does it work better or still jump? You could have it play from =
zero on buffer full to manually tell it to start playing from the =
beginning or you could seek to the front when the buffer gets full. I'll =
try some testing if I can find a dialup...

Good luck,
Jake=20
[vbcol=seagreen]
Hi everyone,
I am currently trying to optimize recordings and playback for dialup =
users.=20
For my recording app I use a maximum recording time of 30 seconds and I =
set
bufferLength to 30 before a user starts recording. This works well even on
dialup (it just takes some time for the buffer to empty, (label this as
'uploading') and allows for pretty good quality recordings to be made even
on dialup.
As these are very small recordings I decided to use progressive download =
for
replay. Again this works well, especially for DSL/cable but not so well on
dialup...=20

Here's the problem:
Once a user has finished recording and hits replay I pull in the just
recorded video via progressive download. BufferTime can still be set on =
null
connections so what I do is I keep track of the recording time and set the
buffer to the length of the recording. In theory this should play back the
entire recording smoothly regardless of connection speed (once buffering =
is
finished). Am I correct so far?

I have an utility called Netlimiter which allows me to throttle my
connection speed. If I set it to dialup speed and make a recording then =
this
works fine. Upon replay I first see frame 1, followed by buffering (ok so
far), once the buffer is full however the video jumps several seconds into
the recording and plays from there...=20
If I change my connection speed to DSL then the recording plays smoothly =
all
the way through which proves that the rcording process went well and all
data is actually contained inside the flv.

Here are my traces for ns.time on dialup, traced every 200ms:
0 // frame 1 shows
0
0
0
0
0
0
0
0
3.893 // NetStream.Buffer.Full received, video still doesn't play
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
3.893
4.025 // video plays smooth from here
4.249
4.537
4.761
5.049
5.305
5.571 // end of the recording


Compare this to the traces on DSL speed:

0
0
0
0
0.473 // NetStream.Buffer.Full received, video plays smoothly
0.665
0.953
1.177
1.401
1.689
1.977
2.201
2.489
2.777
3.001
3.289
3.545
3.833
4.057
4.345
4.633
4.889
5.145
5.401
5.571 // end of the recording

I can't make sense of this. Can anyone else?

Stefan









=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com=20
=3D-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Stefan Richter

2005-04-07, 5:56 pm

Thanks for the reply Jake.
That's exactly why I post on this list - I haven't even thought of seeking
back and playing from start! Let's hope it works.

I'll try the 90% buffer also.

What confused me the most is that the recording itself works exactly as
planned on dialup. I can make recordings that are not normally possible at
that quality. But the replay somehow falls apart a little...

I can really recommend Netlimiter for testing apps under different bandwidth
conditions. It allows you to finely throttle each running app separately
etc.

Thanks again

Stefan



> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Jake Hilton
> Sent: 31 March 2005 18:40
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> Subject: Re: [FlashComm] Buffering problems on dialup
>
> Stefan,
> This doesn't make much sense the way it works... I guess if
> you have it buffer 90% does it work better or still jump? You
> could have it play from zero on buffer full to manually tell
> it to start playing from the beginning or you could seek to
> the front when the buffer gets full. I'll try some testing if
> I can find a dialup...
>
> Good luck,
> Jake
>
> Hi everyone,
> I am currently trying to optimize recordings and playback for
> dialup users.
> For my recording app I use a maximum recording time of 30
> seconds and I set bufferLength to 30 before a user starts
> recording. This works well even on dialup (it just takes some
> time for the buffer to empty, (label this as
> 'uploading') and allows for pretty good quality recordings to
> be made even on dialup.
> As these are very small recordings I decided to use
> progressive download for replay. Again this works well,
> especially for DSL/cable but not so well on dialup...
>
> Here's the problem:
> Once a user has finished recording and hits replay I pull in
> the just recorded video via progressive download. BufferTime
> can still be set on null connections so what I do is I keep
> track of the recording time and set the buffer to the length
> of the recording. In theory this should play back the entire
> recording smoothly regardless of connection speed (once
> buffering is finished). Am I correct so far?
>
> I have an utility called Netlimiter which allows me to
> throttle my connection speed. If I set it to dialup speed and
> make a recording then this works fine. Upon replay I first
> see frame 1, followed by buffering (ok so far), once the
> buffer is full however the video jumps several seconds into
> the recording and plays from there...
> If I change my connection speed to DSL then the recording
> plays smoothly all the way through which proves that the
> rcording process went well and all data is actually contained
> inside the flv.
>
> Here are my traces for ns.time on dialup, traced every 200ms:
> 0 // frame 1 shows
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 3.893 // NetStream.Buffer.Full received, video still doesn't play
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 4.025 // video plays smooth from here
> 4.249
> 4.537
> 4.761
> 5.049
> 5.305
> 5.571 // end of the recording
>
>
> Compare this to the traces on DSL speed:
>
> 0
> 0
> 0
> 0
> 0.473 // NetStream.Buffer.Full received, video plays smoothly
> 0.665
> 0.953
> 1.177
> 1.401
> 1.689
> 1.977
> 2.201
> 2.489
> 2.777
> 3.001
> 3.289
> 3.545
> 3.833
> 4.057
> 4.345
> 4.633
> 4.889
> 5.145
> 5.401
> 5.571 // end of the recording
>
> I can't make sense of this. Can anyone else?
>
> Stefan
>
>
>
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>



=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Jake Hilton

2005-04-07, 5:57 pm

Stefan,
I'll look into Netlimiter... it seems that for no money I can only get a =
28 day trial... well I guess for a month I can trouble shoot this problem. =


Thanks,
Jake

Thanks for the reply Jake.
That's exactly why I post on this list - I haven't even thought of seeking
back and playing from start! Let's hope it works.

I'll try the 90% buffer also.=20

What confused me the most is that the recording itself works exactly as
planned on dialup. I can make recordings that are not normally possible at
that quality. But the replay somehow falls apart a little...

I can really recommend Netlimiter for testing apps under different =
bandwidth
conditions. It allows you to finely throttle each running app separately
etc.

Thanks again

Stefan

=20
[vbcol=seagreen]
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org=20
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of=20
> Jake Hilton
> Sent: 31 March 2005 18:40
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org=20
> Subject: Re: [FlashComm] Buffering problems on dialup
>=20
> Stefan,
> This doesn't make much sense the way it works... I guess if=20
> you have it buffer 90% does it work better or still jump? You=20
> could have it play from zero on buffer full to manually tell=20
> it to start playing from the beginning or you could seek to=20
> the front when the buffer gets full. I'll try some testing if=20
> I can find a dialup...
>=20
> Good luck,
> Jake=20
>=20
> Hi everyone,
> I am currently trying to optimize recordings and playback for=20
> dialup users.=20
> For my recording app I use a maximum recording time of 30=20
> seconds and I set bufferLength to 30 before a user starts=20
> recording. This works well even on dialup (it just takes some=20
> time for the buffer to empty, (label this as
> 'uploading') and allows for pretty good quality recordings to=20
> be made even on dialup.
> As these are very small recordings I decided to use=20
> progressive download for replay. Again this works well,=20
> especially for DSL/cable but not so well on dialup...=20
>=20
> Here's the problem:
> Once a user has finished recording and hits replay I pull in=20
> the just recorded video via progressive download. BufferTime=20
> can still be set on null connections so what I do is I keep=20
> track of the recording time and set the buffer to the length=20
> of the recording. In theory this should play back the entire=20
> recording smoothly regardless of connection speed (once=20
> buffering is finished). Am I correct so far?
>=20
> I have an utility called Netlimiter which allows me to=20
> throttle my connection speed. If I set it to dialup speed and=20
> make a recording then this works fine. Upon replay I first=20
> see frame 1, followed by buffering (ok so far), once the=20
> buffer is full however the video jumps several seconds into=20
> the recording and plays from there...=20
> If I change my connection speed to DSL then the recording=20
> plays smoothly all the way through which proves that the=20
> rcording process went well and all data is actually contained=20
> inside the flv.
>=20
> Here are my traces for ns.time on dialup, traced every 200ms:
> 0 // frame 1 shows
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 3.893 // NetStream.Buffer.Full received, video still doesn't play
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 3.893
> 4.025 // video plays smooth from here
> 4.249
> 4.537
> 4.761
> 5.049
> 5.305
> 5.571 // end of the recording
>=20
>=20
> Compare this to the traces on DSL speed:
>=20
> 0
> 0
> 0
> 0
> 0.473 // NetStream.Buffer.Full received, video plays smoothly
> 0.665
> 0.953
> 1.177
> 1.401
> 1.689
> 1.977
> 2.201
> 2.489
> 2.777
> 3.001
> 3.289
> 3.545
> 3.833
> 4.057
> 4.345
> 4.633
> 4.889
> 5.145
> 5.401
> 5.571 // end of the recording
>=20
> I can't make sense of this. Can anyone else?
>=20
> Stefan
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com=20
> =3D-----------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailma...fo/flashcomm=20
>=20
>=20
> =3D---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com=20
> =3D---------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailma...fo/flashcomm=20
>=20



=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com=20
=3D-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Stefan Richter

2005-04-07, 5:57 pm

Hehe yes it's not free.

I tried your suggestion and changing the buffer to 90% unfortunately didn't
help.
The rewind trick was better, but still not quite right because after the
rewind there comes a second buffer.full message which messed up my logic a
bit. I have worked around this by introducing another variable and while
this works ok-ish it doesn't seem rock solid.

Plus I hate it when I can't get to the bottom of the problem? Why should a
stream not play smoothly when fully buffered? Why the weird jumps in
ns.time?

Cheers

Stefan



> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Jake Hilton
> Sent: 01 April 2005 16:46
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> Subject: RE: [FlashComm] Buffering problems on dialup
>
> Stefan,
> I'll look into Netlimiter... it seems that for no money I can
> only get a 28 day trial... well I guess for a month I can
> trouble shoot this problem.
>
> Thanks,
> Jake
>
> Thanks for the reply Jake.
> That's exactly why I post on this list - I haven't even
> thought of seeking back and playing from start! Let's hope it works.
>
> I'll try the 90% buffer also.
>
> What confused me the most is that the recording itself works
> exactly as planned on dialup. I can make recordings that are
> not normally possible at that quality. But the replay somehow
> falls apart a little...
>
> I can really recommend Netlimiter for testing apps under
> different bandwidth conditions. It allows you to finely
> throttle each running app separately etc.
>
> Thanks again
>
> Stefan
>
>
>
> you have
> buffer gets
> for dialup
> seconds and
> to empty,
> to be made
> DSL/cable
> in the just
> still be set
> recording time
> video jumps
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>



=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Jake Hilton

2005-04-07, 5:57 pm

No kidding.... seems like the player should act the same whether it's =
getting data quickly or slowly..as long as the logic is correct for =
playing the file. Quite annoying.

Best of luck.

Jake

Hehe yes it's not free.

I tried your suggestion and changing the buffer to 90% unfortunately =
didn't
help.=20
The rewind trick was better, but still not quite right because after the
rewind there comes a second buffer.full message which messed up my logic a
bit. I have worked around this by introducing another variable and while
this works ok-ish it doesn't seem rock solid.=20

Plus I hate it when I can't get to the bottom of the problem? Why should a
stream not play smoothly when fully buffered? Why the weird jumps in
ns.time?

Cheers

Stefan
=20
=20
[vbcol=seagreen]
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org=20
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of=20
> Jake Hilton
> Sent: 01 April 2005 16:46
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org=20
> Subject: RE: [FlashComm] Buffering problems on dialup
>=20
> Stefan,
> I'll look into Netlimiter... it seems that for no money I can=20
> only get a 28 day trial... well I guess for a month I can=20
> trouble shoot this problem.
>=20
> Thanks,
> Jake
>=20
> Thanks for the reply Jake.
> That's exactly why I post on this list - I haven't even=20
> thought of seeking back and playing from start! Let's hope it works.
>=20
> I'll try the 90% buffer also.=20
>=20
> What confused me the most is that the recording itself works=20
> exactly as planned on dialup. I can make recordings that are=20
> not normally possible at that quality. But the replay somehow=20
> falls apart a little...
>=20
> I can really recommend Netlimiter for testing apps under=20
> different bandwidth conditions. It allows you to finely=20
> throttle each running app separately etc.
>=20
> Thanks again
>=20
> Stefan
>=20
> =20
>=20
> you have=20
> buffer gets=20
> for dialup=20
> seconds and=20
> to empty,=20
> to be made=20
> DSL/cable=20
> in the just=20
> still be set=20
> recording time=20
> video jumps=20
>=20
>=20
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com=20
> =3D-----------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailma...fo/flashcomm=20
>=20
> =3D---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com=20
> =3D---------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailma...fo/flashcomm=20
>=20



=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com=20
=3D-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com