Na einfach die Zahlungen "verweigern" wird nichts bringen, das ist (aus rechtlicher Seite gesehen, nicht aus Moralischer) dann für "die" ein extra Anlass noch Stress zu machen ..., und darüberhinaus verdienen die doch genau daran ...
Ein klarer Rechtsweg wird in diesem Fall wohl nicht unumgänglich sein.
Also im Groben:
- Informieren, Fristen zur Nachbesserung einhalten ;
- Reklamieren und def. Frist zur behebung der Probleme setzen, Frist abwarten.
- Wenn nichts brauchbares passiert ... den offiziellen Rechtsweg einschlagen und Anwalt konsultieren.
Dabei sollte man sich vorher darüber im klaren sein, dass so ein Verfahren durchaus mal 2 Jahre und viel Geld kosten kann.
Die andere Seite ist, ob man "nur" Zivilrechtlich vorgeht, oder auch Strafrechtlich vorgehen möchte.
Denn " ... wer eine Dienstleistung anbietet, die er -offensichtlich- nicht im stande ist zu erbringen, der macht sich des Betrugsversuches verdächtig" .. mal so ganz grob gesagt.
Darüberhinaus gehts dann noch in Richtung §§ "Irreführende Werbung" ect. ect ...
(unverbindlich, ich bin kein Rechtsberater, das ist "nur" meine Meinung.)
Die originalen Gesetzestexte möchte ich hier jetzt nicht zitieren, und die Urteile aus solchen verfahren auch nicht. Das würde diesen Post sprengen
Nebenbei: Wir haben sogar 7-Punk messungen und Analysen vorgenommen, mit Fachlicher Anleitung einer TFH und einer TU. (intern zwischen Servern von S4Y, extern zum vergleich und innerhalb zweier anderer Serveranbieter.)
Bei S4Y ist eine extreme Netzüberlastung (im Verhältnis zum internen netzausbau) zu bestimmten Zeiten zu vermuten. Sieht fast so aus als wenn Viele Nutzer bei S4U ihre Vollbackups täglich zu fast der gleichen Zeit machen. Oder es hängen auf nem 6,3 GBit Backbone 2000 Serverchen von denen gerade in den Abendstunden so 100 etwas Fullspeed-Filesharing betreiben. Da bleibt nich mehr viel an Qualität übrig, wenn der Backbone nicht auf ein entsprechendes Limit gedrosselt wird.
hier mal noch nen aktuelles mtr, zum "nachdenken" , gerade frisch gemacht:
Code:
HOST: D3@s4y(DB). . . . . . . . . . Loss% Snt Last Avg Best Wrst StDev
1. static-ip-85-25-136-1.inaddr . . .0.0% 1000 8.0 4.5 0.5 583.8 25.0
2. static-ip-85-25-255-209.inad . . 0.0% 1000 7.7 3.9 1.4 21.2 3.0
3. Intergenia-TEN.FRA-2-eth130- . 0.3% 1000 3.6 5.0 0.3 116.1 12.3
4. FRA-11-pos300.de.lambdanet.n. 0.4% 1000 8.0 6.7 0.5 144.2 17.7
5. Intergenia-DUS3.de.lambdanet . 4.8% 1000 97.2 13.6 3.7 148.1 21.1
6. RA@s4y(kws) . . . . . . . . . . . . 14.1% 1000 12.2 6.8 3.9 16.2 2.5
Code:
HOST: RA@s4y(kws) . . . . . . . . Loss% Snt Last Avg Best Wrst StDev
1. static-ip-85-25-6-3.inaddr.i . . 10.7% 1000 1.3 7.7 0.4 153.9 19.1
2. Intergenia.FRA-11-eth0-105.d. 11.2% 1000 68.7 8.3 3.6 154.7 16.3
3. Intergenia-INX.de.lambdanet. . 15.5% 1000 5.9 6.7 5.2 14.9 1.0
4. static-ip-85-25-255-218.inad . 17.2% 1000 5.4 8.4 4.4 543.1 32.4
5. D3@s4y(DB). . . . . . . . . . . . . 14.6% 1000 4.9 5.0 3.8 9.6 0.4
... da passt bei s4y durch die internen leitungen kaum noch ne einfache HTML-Seite , also quasi auf dem Rückroute geht fast nichts mehr durch ...
Am Ende: nen 3 Euro- V-Server (die gibts gerade in Östereich) läuft momentan um Welten besser als nen grosser Rootserver von server4You.