I have now stumbled upon a problem found elsewhere: a freezing Ethernet shield. It seems there are two known problems: cold start bug and freeze at some moment in time.
For the cold start bug a suggestion was made to use Ethernet.begin twice. This would not be constructing anything, it merely initializes the Ethernet chip. So you can do it twice.
My question would be: could that be used to solve the freezing as well? As soon as you discover that there is no more connection possible then simply re-issue Ethernet.begin(). And if this would work: what would that mean for the Webduino that was initialised on top of the Ethernet stack? Does that continue to work or does it fail after the Wiznet chip has reset itself?
I think if you reset the Ethernet controller using Ethernet.begin(), you'll probably need to also add a reset function to the Webduino code to have it reconfigure it's listening port, as I'd not expect that configuration to survive the reset.
I thought so... I'll look into it, although I am not quite sure if "soft-resetting" the Ethernet shield will solve anything... If you have tips as to how to reset Webduino: feel free to add some pointers.
Ben knows better than I about effects on Webduino (I contributed some additions to it, but it's his baby), but I have a system running now using the standard Server class that seems to survive doing hardware resets of the Wiznet. Which might just be dumb luck: now that you've brought this up, I need to look under the hood, myself.
I do the hardware resets of the Wiznet using a digital pin wired to the Wiznet pin in lieu of connecting it to the Arduino's reset line: do a forum search for something like "ethernet reset" to find threads about problems people have encountered with the Wiznet not resetting correctly, and how to do the hardware and software changes to support "program-controlled" resets.