[.NET] WCF, NetTcpBinding over internet, waarom niet?

[Verwijderd]

Tweakerts,

Stel je het volgende scenario voor:
- WCF services in gehost in een windows service
- Colocated server
- 5 tot 30 consumers, over internet
- Clients zijn zelf geschreven WinForms applicaties
- Geen compatibiliteitseisen
- Geen loadbalancing
- Geen proxies

Momenteel gebruik ik in de services WSHttpBinding. Authenticatie laat ik buiten beschouwing en daar gaat dit verhaal eigenlijk niet over.

Ik zag laatst een grafiekje voorbij komen van de performance van de NetTcpBinding vs de WSHttpBinding en dus WSDualHttpBinding (die laatste gaan we nodig hebben aangezien we binnenkort iets met callbacks gaan doen). NetTcpBinding presteert duidelijk beter dankzij de binaire serialisatie (die overigens ook met Http te gebruiken is) en andere optimalisaties.

Nu zie je overal op MSDN binnen 10 worden van TcpNetBinding staan "for Intranet use". Kan iemand me dan vertellen (op bovengenoemde, en dus in deze context niet relevante, genoemde punten na) waarom je NetTcpBinding niet over internet zou moeten gebruiken?

[Xiphalon]

Omdat MS ervanuitgaat dat je HTTP verkeer zonder problemen door alle firewalls heen kan duwen?

En net.tcp over het algemeen over andere poortnummers gaat, wat dus voor firewallproblemen kan leiden?

[pasz]

Als je je client ook zelf ontwikkeld, maakt het niet uit wat je gebruikt.

Met andere woorden, als je je webservice niet voor andere doeleinden/platforms/clients hoeft te exposen, kun je gewoon het snelste gebruiken. Zoals eerder opgemerkt, wel rekening houden met het port-nummer ivm firewalls.

[Xiphalon]

Dat is inderdaad ook een goeie. WSHttpBinding is standaard en Net.tcp niet. Maar als je client en server zelf in beheer hebt (meestal in een Intranet situatie) is de standaard niet echt nuttig.

Maar als je de eindgebruikers van je client ook niet echt kan controleren blijft WSHttp handiger ipv net.tcp door de firewall issues.

[ Voor 26% gewijzigd door Xiphalon op 12-05-2009 19:03 ]

[Verwijderd]

Firewall issue == support == facturen.
Huh zei ik iets ;-).

Edit: firewalls zijn geen issue (we deployen de clients meestal on-site).

[ Voor 40% gewijzigd door Verwijderd op 12-05-2009 19:15 ]

[Niemand_Anders]

Het heeft niet zozeer met de firewall te maken, maar wel dat de NetTcpBinding de verbinding continue openhoud en WSHttpBinding de verbinding verbreekt als de rpc call is voltooid (hoewel je ook een keepalive kunt instellen). Immers kun je de NetTcpBinding ook gewoon instellen op poort 80.

Webservers kunnen zoveel clients bedienen omdat ze allemaal kortstondig zijn verbonden. Als je 1000 asp.net sessies hebt, zul je ongeveel 5-10 concurrent connections hebben. Dat geldt ook voor de *HttpBindings in WCF, daar hebben 1000 clients dan geen 1000 connecties openstaan, terwijl dat bij de NetTcpBinding wel zo is. De NtpTcpBinding is dus veel gevoeliger voor (D)DOS attacks.

Op een intranet (lees: gecontroleerde netwerk omgeving) kun je een goede voorspelling doen van het aantal clients (connecties) doen en daarom raad Microsoft de NetTcpBinding alleen aan bij intranet gebruik. Als je echter zoals je zelf aangeeft het aantal clients is beperkt tot +/- 30 dan is er geen enkele reden waarom je niet NetTcpBinding kunt gebruiken.

[ Voor 3% gewijzigd door Niemand_Anders op 13-05-2009 10:06 ]

[Verwijderd]

Dat bevestigd mijn vermoeden Niemand_Anders.
Spreek je uit ervaring overigens of uit redenatie?

[D-Raven]

Ik denk beide .

Maar het klopt wel wat Niemand_Anders zegt.

[Niemand_Anders]

Als je een WCF <--> WCF implementatie hebt (je hebt controle over zowel de server als de client) dan kun je natuurlijk ook de binary serializer gebruiken in combinatie met WebHttpBinding. Dat vereist wel aanpassingen aan zowel de client als server kant.

Als je door middel van een firewall de toegang tot je service kunt beperken (bijv. via IP controle) is NetTcpBinding een veilige keuze. Op MSDN staat een artikel waarin wordt aangegeven bij welke situatie welk transport layer wordt aangeraden.

Hoewel er inmiddels al een aantal goede boeken zijn verschenen voor WCF, vind ik Enterprise Service Bus (ESB) primers een betere focus hebben over de keuze van de transport layer. WCF boeken hebben de focus vooral op development, configuratie en messaging. De verschillende transport layers worden helaas meestal miniem besproken.

Een alternatief voor de zware WCF binary serialisatie is Google's Protocol Buffers specificatie. Ik gebruik de protocol buffers al langer in combinatie met zowel WCF als de Rhino Enterprise Service Bus. In WCF behaalde ik tot 15% meer performance bij een lagere CPU usage.

[D-Raven]

offtopic:
Vroeg zich af in hoeverre de protocol buffer spec werkt ten opzichte van de NetDataContractSerializer. Dit laatste heeft namelijk als voordeel dat je "niet meer" met KnownTypes aan de slag hoeft indien je met subclassering e.d werkt in je service messages.

[Niemand_Anders]

D-Raven schreef op woensdag 13 mei 2009 @ 18:38:

offtopic:
Vroeg zich af in hoeverre de protocol buffer spec werkt ten opzichte van de NetDataContractSerializer. Dit laatste heeft namelijk als voordeel dat je "niet meer" met KnownTypes aan de slag hoeft indien je met subclassering e.d werkt in je service messages.

In WCF weet je in principe altijd naar welk type de data moet worden omgezet. Door het interface contract weet zowel de client als server welk (basis) type wordt verwacht. De protobuf probeert het bericht naar dit type om te zetten. Dus stel dat je een abstracte class BaseEntity hebt en een concrete implementatie User dan de service een BaseEntity verwacht, dan zal het object worden omgezet naar de BaseEntity en niet naar User. De protobuf spec houd hier dus eigenlijk het Liskov Substitution Principle aan.

De WCF implementatie doet dan dus feitelijk Serializer.Deserialize<BaseEntity>(inputStream). Voor de duidelijkheid is dit gedrag onderdeel van de protobuf implementatie en niet protobuf zelf. Omdat de protobuf bij de serializatie data niet opslaat wat het originele type was, moet de ontvanger dus aangeven wat het verwacht. De WCF implementatie gebruikt hierom dus de contract informatie.

[D-Raven]

Niemand_Anders schreef op donderdag 14 mei 2009 @ 11:04:

De WCF implementatie doet dan dus feitelijk Serializer.Deserialize<BaseEntity>(inputStream). Voor de duidelijkheid is dit gedrag onderdeel van de protobuf implementatie en niet protobuf zelf. Omdat de protobuf bij de serializatie data niet opslaat wat het originele type was, moet de ontvanger dus aangeven wat het verwacht. De WCF implementatie gebruikt hierom dus de contract informatie.

offtopic:
Helder Ik zag dat protobuf de Order parameter van het DataMember attribuut gebruikt om dat aan te geven.
Binnenkort maar eens wat tijd inruimen om hiermee te gaan prutsen.

[Verwijderd]

M.b.t. DoS opmerking:
http://msdn.microsoft.com...cethrottlingbehavior.aspx
(Je bent met de juiste afstelling iig minder gevoelig) maar goed dat je me eraan herinnerd hebt ;-).

[Niemand_Anders]

Zelfs met de juiste instellingen kan ik je service onbereikbaar maken (het doel van de attack). Stel jij staat slechts 10 connecties toe. Het enigste wat ik hoef te doen is per seconde 20 connecties nar jouw machine maken en jouw server is onbereikbaar voor de buitenwereld. Je service draait nog wel, maar men zal slechts sporadisch ermee kunnen connecten.

Voor mij (als hacker) maakt het niet uit om wat voor reden jouw service onbereikbaar is.Als .NET developer heb je vast wel IIS (PWS) geinstalleerd. Ga eens naar localhost met je browser en houd de F5 toets maar eens een tijdje ingedrukt. Op een gegeven moment krijg je vanzelf de foutmelding dat er teveel connecties naar de machine zijn. Techinisch gezien heb je zojuist je eigen machine een DOS (Denial Of Service) attack uitegevoerd.Die 10 connecties die PWS toestaat is gebaseerd throttling. Heeft dat de DOS verkomen of je machine er minder gevoelig voor gemaakt?

Daarom als je TCP verbindingen over internet toestaat, zorg dan in elk geval dat je via bijvoorbeeld een firewall bepaald wie toegang tot jouw services heeft. Je kunt ook op firewall niveau bepalen dat vanaf elk IP slechts 5 conecties (statefull firewalling) mogelijk zijn. Dat vind ik persoonlijk een betere oplossing dan bij je service opgeven dat deze maximaal 40 clients mag bedienen.

Zelf gebruik ik tijdens development de HttpBinding en stem daarop mijn messages af. Bij ons is de performance van de HttpBinding de standaard. Hierdoor zullen developers minder snel overbodige informatie oversturen. Stel je hebt een Ecommerce catalog service welke GetProductsForCategory aanbied. Op het moment dat jij alle properties van een product in een message plaats en deze via HTTP binding overstuurt wordt de service al snel traag. Geef je allen het ProductID, Title en Price terug dan is het geheel een stuk sneller. Een top 10 service geeft dus alleen 10 productid's terug. Wij noemen dat intern Message Driven Development.

In de productie omgeving gebruiken wij echter de NetTcpBinding met PB serialisatie. Maar dat is wat mij betreft dezelfde optimalisatie als dat je in een productie omgeving geen debug build gebruikt.

[Verwijderd]

Zo... ik kom nog even terug op dit onderwerp.

Na je (Niemand_anders) advies geen NetTcp te gebruiken over internet heb ik een implementatie gemaakt met WsDualHttp. In de testomgeving werkte dit prima. Echter in de productie omgeving (waar de server achter een hardwarematige firewall zit) ging het mis.

Ik had WsDualHttp gekozen over WsHttp omdat callbacks een vereiste zijn. Zoals je weet is WsDualHttp een WsHttp "hack" waar er twee WsHttp kanalen opgezet worden. Echter stopte de firewall het kanaal (TCP verbinding) waarover de callbacks gingen (deze ging over een random poort en werd kennelijk (??) geïnitieerd vanuit de client [client.80 <=> server.random) geblokkeerd door de firewall. Wat er ook gebeurde, de firewall was er niet blij mee.

Dus ging ik hier informeren hoe ik dat gedrag kon controleren zodat ik de firewall kon configureren.

Daar kwam echter weer die discussie over NetTcp op gang en daar verteld iemand mij dat NetTcp even gevoelig is voor DoS als WsDualHttp. Mocht jouw punt gaan over WsHttp vs NetTcp (ipv WsDualHttp vs NetTcp) dan bedoel je dus dat alle fullduplex connecties kwetsbaar zijn?

In ieder geval gebruik ik nu NetTcp over internet ( (zonder firewall problemen, callbacks gaan over een endezelfde TCP verbinding). Ik wou, gezien je kennis op dit gebied, graag nog even je mening horen over de comments van Richard Blewett.

[Niemand_Anders]

Allereerst is WCF een messging systeem. Je stuurt een request en krijgt een response terug. Callbacks in messaging systemen is vragen om moeilijkheden. WCF is geen remote object/CORBA implementatie (zoals System.Runtime.Remoting)

Ik neem aan dat je weet hoe HTTP werkt. Jij stuurt een request als 'GET /index.aspx HTTP/1.1' en krijgt vervolgens een response terug. Door de keep-alive kan de browser via dezelfde verbinding images, stylesheets en andere resources opvragen.

Echter een callback is een speciaal iets. Een callback is eigenlijk om omgedraaide request (want niet de client maakt verbinding met de server, maar de server probeert verbinding te maken met de client). Echter vrijwel alle clients zitten achter een NAT gateway. Standaard zal een callback request worden geinitialiseert op de source poort welke is gebruikt bij het request waarin de callback is gezet. Laten we even aanhouden dat de WCF proxy client source poort 1866 gebruikt om de request message naar de server te sturen. De WCF client houd deze poort vast zodat deze niet door een ander process gebruikt kan worden. Op het moment dat de server de callback wil uitvoeren maakt deze een verbinding met poort 726. Er wordt dus niet zomaar een random poort gekozen. Zoals je zelf hebt gemerkt werkt dit fantastisch in je testomgeving.

In een productie omgeving bevind de server zich meestal niet in hetzelfde subnet als de client en staat de client bovendien achter een NAT gateway. Nu gaan de dingen een beetje anders:
client maakt vanaf 10.0.0.4:726 verbinding met server 194.109.1.2:80. De gateway onderschept dit en zal past de packets aan en stuurt vervolgens je request door. Echter nu is de source niet meer juw client ip, maar het externe ip van de gateway en zal meestal ook een andere source poort hebben. De server ontvangt in dit geval dus niet een request van 10.0.04:726, maar vanaf 194.106.32.1:8356. De server verwerkt het request en stuurt een response terug naar de gateway. De gateway weet dat de response weer doorgestuurt moet worden naar jouw client. Tot zover werkt alles zoals dat ook met een browser werkt.

Maar nu komt de callback. De server probeert nu een verbinding te maken met 194.106.32.1:8356 om de callback uit te voeren. Echter de gateway heeft de mapping 10.0.0.4:726<-->194.106.32.1:8356<-->194.109.1.2:80 verwijderd en zal dus de connectie van de server weigeren en dus komt de callback nooit terug bij de client. Daarnaast mogen ook veel servers wegens security overwegingen zelf geen HTTP verbindingen opbouwen (hooguit met enkele update servers).

Omdat jouw client overigens nooit de callback ontvangt, houd de WCF service de poort theoretisch oneindig in gebruik.


Zoals al eerder in de topic gemeld is er technisch gezien geen enkele belemmering om NetTcp te gebruiken. Echter NetTcp is een 'plain' telnet socket zonder verdere beschermings opties. De standaard timeout staat op Int32.MaxValue seconden. Uit zichzelf zal WCF dus nooit opgebouwde tcp connecties sluiten.

Zonder keep-alive zal een webserver de verbinding direct sluiten nadat deze de response heeft gestuurd. Als de webserver geen request ontvangt zal deze de verbinding al naar enkele seconden sluiten. Mailservers welke ook via TCP communiceren implementeren een soort gelijk gedrag. WCF doet dat bewust niet uit zichzelf omdat dit via uitbreidingen toegevoegd kan worden. Door bijvoorbeeld een eigen IInstanceProvider implementatie te schrijven kun *jij* bepalen hoe objecten aangemaakt moeten worden zoals via een DI framework.

Dit gegeven maakt dat NetTcp gevoeliger is voor DoS attacks dan WsHttp. WsDualHttp is wel iets gevoeliger voor DoS attacks dan WsHttp, maar weer minder dan NetTcp. Want de beveiligingen welke gelden voor een webserver gelden dan ook voor jouw client (WsDualHttp geeft alleen aan dat vanuit het niets verbinding met jouw client (niet de server) gemaakt kan worden. WsDualHttp wordt veel in distributed schemas gebruikt.

Kijk de kans dat een hacker jouw het leven zuur gaat maken is natuurlijk erg klein. Via WCF configuratie kun je WCF ook redelijk in stellen. In elk geval moet je even kijken naar de verschillende timeouts welke in WCF en NetTcp aanwezig zijn en deze voor je service(s) instellen.

Op het moment dat je met callbacks en events wilt werken is het erg verstandig om eerst naar remote objects te werken. Daarnaast moet opgemerkt worden dat async callbacks niet door de server, maar door de proxy worden getriggert. De server zelf kent geen synchronen of asynchrone callbacks omdat WCF in de kern gewoon een request-response systeem blijft. Het is de proxy aan de client kant welke een call blocking maakt of niet..

[Verwijderd]

Ok bedankt voor je feedback, helder verhaal.

Ik heb de tijd niet om dit project met .NET remoting aan te pakken, en ook met andere projecten zal een remoting aanpak vele malen meer tijd kosten dan het mooi geautomatiseerde WCF. Met CORBA heb ik persoonlijk nog geen ervaringen maar we zijn dit project nu eenmaal in .NET begonnen.

Toch vind je opmerking over de callbacks wat overdreven sceptisch. Ik snap waarom je vind dat callbacks niet binnen "request-respond / client/server architectuur" passen. Maar waarom zouden de "requests" (zoals bij HTTP) altijd een kant uitgaan?

De kans dat ik last krijg van hackers is klein natuurlijk. Het is een relatief kleinschalig project en de server doet verder niets buiten de services aanbieden, je moet wel overdreven scannen wil je die tegenkomen. Toch is security onderdeel van kwaliteit en dat wil ik bij elk project even meenemen ;-).

Edit: Over WsDualHttp lees ik veel sceptische berichten.

[ Voor 3% gewijzigd door Verwijderd op 10-06-2009 14:03 ]

[Niemand_Anders]

Verwijderd schreef op woensdag 10 juni 2009 @ 13:58:
Toch vind je opmerking over de callbacks wat overdreven sceptisch. Ik snap waarom je vind dat callbacks niet binnen "request-respond / client/server architectuur" passen. Maar waarom zouden de "requests" (zoals bij HTTP) altijd een kant uitgaan?

Omdat het HTTP protocol zo ontworpen is? De callbacks hebben niets met de client/server architectuur te maken, maar eerder dat WCF een MESSAGING service is. Daarom moet je ook een data contract specificeren, want dat zijn de gegevens welke je overstuurt. Omdat bericht (+ de data) bij de bestemming te krijgen gebruik je een transport zoals HTTP, SMTP of NetTcp.

De reden dat de callbacks bij jouw op de productie niet werken heeft niets te maken met het HTTP of de WCF protocollen, maar is een puur NAT/gateway probleem. In je signature staat dat je een infrastructure specialist bent, dus zou je dat toch echt moeten weten. WCF moet je (blijven) zien als webservices op anabolen.

De kans dat ik last krijg van hackers is klein natuurlijk. Het is een relatief kleinschalig project en de server doet verder niets buiten de services aanbieden, je moet wel overdreven scannen wil je die tegenkomen. Toch is security onderdeel van kwaliteit en dat wil ik bij elk project even meenemen ;-).

Security behoort de basis van elk project te zijn. Het is een cliché, maar het is wel de praktijk. Door je service over de HTTP transport te laten communiceren zullen hackers voornamelijk IIS en Apache hacks loslaten op je service en daar is WCF niet gevoelig voor. Op het moment dat je hem als TCP service beschikbaar maakt worden de mogelijkheden wat groter en dat heeft vooral met het ontbreken van gedrag te maken. SMTP, FTP en HTTP voegen allemaal gedrag in de vorm van timeouts toe om misbruik zoveel mogelijk tegen te gaan.

Onze services zijn bijvoorbeeld alleen benaderbaar vanaf een Europees IP (uitgegeven door RIPE).

Edit: Over WsDualHttp lees ik veel sceptische berichten.

En dat is vrij logisch omdat webservers uit zichzelf geen verbinding behoren te zoeken met de client. Bij een callback houd WCF de poort tijdelijk open, bij wsDualHttp blijft de poort openstaan en kan de webserver messages pushen. Echter webservers welke zelf verbindingen starten zijn een big no-no.

[Verwijderd]

Omdat het HTTP protocol zo ontworpen is? De callbacks hebben niets met de client/server architectuur te maken, maar eerder dat WCF een MESSAGING service is. Daarom moet je ook een data contract specificeren, want dat zijn de gegevens welke je overstuurt. Omdat bericht (+ de data) bij de bestemming te krijgen gebruik je een transport zoals HTTP, SMTP of NetTcp.

Ik zei ZOALS (waar ze dus een kant uit gaan) mbt HTTP, ik had het niet over HTTP zelf. Ik meen uit je verhaal op te maken dat WCF een request/response opzet heeft en dat je daarom vind dat callbacks hier niet in thuis horen. Ik ben het daar niet mee eens, en gezien de mogelijkheid van callbacks in WCF meer mensen niet.

De reden dat de callbacks bij jouw op de productie niet werken heeft niets te maken met het HTTP of de WCF protocollen, maar is een puur NAT/gateway probleem. In je signature staat dat je een infrastructure specialist bent, dus zou je dat toch echt moeten weten. WCF moet je (blijven) zien als webservices op anabolen.

Waar heb ik gesteld dat dit aan HTTP of WCF lag? Het probleem zit hem in wie de verbinding initieert en de NAT/Firewall situatie in dat scenario. Daar heb ik nooit getwijfeld en uit de manier waarop je je zin formuleert krijg ik het gevoel dat je me hier een beetje probeert aan te vallen?

Security behoort de basis van elk project te zijn. Het is een cliché, maar het is wel de praktijk. Door je service over de HTTP transport te laten communiceren zullen hackers voornamelijk IIS en Apache hacks loslaten op je service en daar is WCF niet gevoelig voor. Op het moment dat je hem als TCP service beschikbaar maakt worden de mogelijkheden wat groter en dat heeft vooral met het ontbreken van gedrag te maken. SMTP, FTP en HTTP voegen allemaal gedrag in de vorm van timeouts toe om misbruik zoveel mogelijk tegen te gaan.

Security is in mijn optiek zeker NIET de basis van een project. Het is een kwaliteitsaspect. En afhankelijk van de wensen van de klant hang je er een bepaalde waarden aan. Natuurlijk probeer je altijd het maximale eruit te halen. Maar mijn opdrachten draaien niet om security, anders had ik wellicht overwogen "Security specialist" in mijn sig te zetten zodat mensen zoals jij als ik een vraag stel geïrriteerd naar mijn sig kunnen wijzen en roepen dat ik het allemaal niet snap. Je moet je klant natuurlijk goed adviseren maar kwaliteit is mijns inziens de mate waarin je voldaan hebt aan de verwachtingen van je klant en die zal voor zien geld niet altijd alcatraz like beveiliging willen.

Onze services zijn bijvoorbeeld alleen benaderbaar vanaf een Europees IP (uitgegeven door RIPE).

Een van de motivaties achter dit project was mobiliteit mogelijk maken, wel een mooie tip overigens. (Alleen valt Rusland ook onder RIPE NCC ;-))

En dat is vrij logisch omdat webservers uit zichzelf geen verbinding behoren te zoeken met de client. Bij een callback houd WCF de poort tijdelijk open, bij wsDualHttp blijft de poort openstaan en kan de webserver messages pushen. Echter webservers welke zelf verbindingen starten zijn een big no-no.

Mee eens.

Al met al, bedankt voor je inbreng. Maar probeer wat subtieler te zien in je aannemingen over wat ik weet en niet weet en wat ik ben of niet ben, voor je het weet trap je iemand op zijn tenen.

[Niemand_Anders]

Verwijderd schreef op donderdag 11 juni 2009 @ 20:56:
Ik zei ZOALS (waar ze dus een kant uit gaan) mbt HTTP, ik had het niet over HTTP zelf. Ik meen uit je verhaal op te maken dat WCF een request/response opzet heeft en dat je daarom vind dat callbacks hier niet in thuis horen. Ik ben het daar niet mee eens, en gezien de mogelijkheid van callbacks in WCF meer mensen niet.

Ondanks het feit dat WCF inderdaad een request/response message structuur kent (zoals eigenlijk elke middleware software) heeft Microsoft ook twee toepassingen gezien. Namelijk intern gebruik en extern gebruikt. Om de interne communicatie tussen twee WCF services te vereenvoudigen hebben ze dus een aantal functionaliteiten toegevoegd zoals de callbacks (denk aan bijvoorbeeld een cache server welke via een callback aangeeft dat een item is expired). Echter afhankelijk worden van callbacks is erg gevaarlijk omdat lang niet alle transports (Smtp, MSMQ, etc) callbacks ondersteunen.

Waar heb ik gesteld dat dit aan HTTP of WCF lag? Het probleem zit hem in wie de verbinding initieert en de NAT/Firewall situatie in dat scenario. Daar heb ik nooit getwijfeld en uit de manier waarop je je zin formuleert krijg ik het gevoel dat je me hier een beetje probeert aan te vallen?

Dan had ik je verkeerd begrepen en het was al helemaal niet mijn bedoeling om je persoonlijk aan te vallen. Als je wel dat jevoel bied ik je mijn excuses aan. Sorry.

Security is in mijn optiek zeker NIET de basis van een project. Het is een kwaliteitsaspect. En afhankelijk van de wensen van de klant hang je er een bepaalde waarden aan. Natuurlijk probeer je altijd het maximale eruit te halen. Maar mijn opdrachten draaien niet om security, anders had ik wellicht overwogen "Security specialist" in mijn sig te zetten zodat mensen zoals jij als ik een vraag stel geïrriteerd naar mijn sig kunnen wijzen en roepen dat ik het allemaal niet snap. Je moet je klant natuurlijk goed adviseren maar kwaliteit is mijns inziens de mate waarin je voldaan hebt aan de verwachtingen van je klant en die zal voor zien geld niet altijd alcatraz like beveiliging willen.

Security een kwaliteits aspect noemen vind ik heel erg gevaarlijk. Klanten weten niets van security en kunnen dus onmogelijk aan jouw duidelijk maken wat voor soort security zij willen. Jij, als consutant, zal de klant vragen moeten stellen over het gebruik. Uptime en performance zijn kwaliteits aspecten en deze zullen ook terug komen in de SLA. Security, anders dan een vrijwaring voor de hoster, zie ik eigenlijk nooit daar terug komen.

Als je aan een klant vraagt wat voor soort security wil je. Alcatraz like waarbij de kans op een hack 0,000001% (gebaseerd op ruim 10 jaar ervaring met het aanbieden (en hosten) van financiele services aan banken en intermediairs) of een mindere beveiliging waarbij de kans op een hack 0,01% is.
Bij NetTcp moet je allerlei lagen er bovenop gaan bouwen om te voorkomen dat een channel onbeperkt open blijft staan, terwijl andere channels dit al standaard aanbieden.

Wij bieden onze services aan via wsHttp over ssl en waarbij de client geauthoriseerd wordt middels client certificaten uitgegeven door FDN (Financial Data Network).

Een van de motivaties achter dit project was mobiliteit mogelijk maken, wel een mooie tip overigens. (Alleen valt Rusland ook onder RIPE NCC ;-))

Wij hadden vooral last van aziatische ips. Voor adviseurs van intermediairs onderweg hebben wij andere oplossingen zoals via de KPN Dongel een VPN verbinding opzetten met kantoor en vanaf kantoor verbinding maken met onze services.

Al met al, bedankt voor je inbreng. Maar probeer wat subtieler te zien in je aannemingen over wat ik weet en niet weet en wat ik ben of niet ben, voor je het weet trap je iemand op zijn tenen.

Moet je je maar niet op je teentjes laten trappen

Darnaast heb ik ook het idee dat we af en toe en beetje langs elkaar heen praten. Communicatie blijft een lastig iets.