Sitter och ritar på ett klient/server system där servern ska kunna hantera minst 300 samtidiga klienter (helst många fler). Integritet i systemet är viktigt (prio. #1) vilket kräver en krypterad kommunikation samtidigt som man ska kunna skicka filer och accessa servern från både intranät och Internet. Det låter som om du bör använda WebServices även om det kräver IIS. > använda WebServices även om det kräver IIS. 1, titta på remoting.. gär precis det du vill > 1, titta på remoting.. gär precis det du vill. >Läste lite ytligt om det bara i en annan nyhetsgrupp där de rackade ned >på dess prestanda precis som med DCOM om man tolkar det fritt. Men >jag ska ta och titta på det lite närmre och se om detta kan vara något. >Det jag är fundersam på då är om jag måste kryptera alla parametrar >individuellt? Tack för dina fina svar. Remoting kanske blir den lösning jag väljer. Jag ska ta och skriva lite test program och försöka simulera det tänkta scenariot. > Problemet med krypterad kommunikation eller snarare att datat ska vara krypterat kvarstår tyvärr. Du har ett crypto-api (rätt så slött iofs) i frameworket du kan använda, ett annat sätt är att komprimera informationen och kryptera binärpaketen i runtime. Fördelen med det senare är att du minskar nättrafiken betydligt jämfört med att skicka okomprimerade xml-dokument... om jag inte minns fel så kan remoting kryptera kommunikatione med base64 .. men som sagt, det är om jag inte minns fel ... base64 suger, det ökar nätverkstrafiken med 12.5% och det under förutsättning att inga paket blir felaktigt skickade... Rickards förslag om SSL känns betydligt bättre imo... > så kan remoting kryptera kommunikatione med base64 >Remoting kanske blir den lösning jag väljer. Vad jag har förstått så är det ingen skillnad ur programmerings synpunkt på HTTPChannel och TCPChannel så jag tror faktiskt jag gör så jag öppnar två pipor in mot servern. Sedan kan användaren själv om den vill ändra standardinställningen till det andra alternativet.Distribuerad app, kommunikations metod?
Sitter och funderar på vilken typ av kommunikation/metod jag ska använda.
Just nu hade jag tänkt följande:
1. Kommunikation sker över TCP där krypterade (synkron) XML-dokument skickas (serialiserade från objekt).
2. Klienten ansluter, skickar förfrågan/skickar data och stänger anslutningen när den fått svar (samma princip som HTTP).
3. Servern tar emot anslutningen/förfrågan och använder ThreadPool för att bearbeta den och sedan skicka svar så fort som möjligt.
Frågan är om detta är en bra lösning? Kanske skulle klienterna ha en konstant TCP öppen mot servern?
Tar tacksamt emot förslag, kommentarer, kritik etc. Implementation blir med VB.Net/Windows App som klient samt VB.Net/Windows Service som server. Vill också undvika att göra det beroende av IIS eller andra produkter utöver databasen.
Mvh,
Håkan WennerbergSv: Distribuerad app, kommunikations metod?
Sv: Distribuerad app, kommunikations metod?
Nej, Webservises har ingeting med Microsoft, .NET och IIS att göra! Webservices är en öppen standard från W3 [<URL:http://www.w3.org/>] och går att implementera på de flesta platformar.Sv: Distribuerad app, kommunikations metod?
2, när du pratar om att skicka objekt över tråden, akta dig öfr storleken på objekten. Tänk på att det tar rtid att serializer/deserializera objekten i avrje ände. Bättre i ett distribuerat system att skicka all data som parametrar till metoder. en mindre flaskhals att bry sig om..
3, varför implementera en egen threadpool när du har com+ objectpooling ??? Sv: Distribuerad app, kommunikations metod?
Läste lite ytligt om det bara i en annan nyhetsgrupp där de rackade ned på dess prestanda precis som med DCOM om man tolkar det fritt. Men jag ska ta och titta på det lite närmre och se om detta kan vara något. Det jag är fundersam på då är om jag måste kryptera alla parametrar individuellt?
> 2, när du pratar om att skicka objekt över tråden, akta dig öfr storleken på objekten.
Mmm... vad jag hade tänkt var att man serialiserar dem till XML så man får ett rent XML-dokument. Som jag krypterar och sedan skickar.
> 3, varför implementera en egen threadpool när du har com+ objectpooling ???
Om jag har förstått rätt så är klassen ThreadPool med dess statiska metoder ett gränssnitt mot NT-Thread Pool. Provar man att skapa några trådar så ser man på dess "id nummer" att andra trådar man själv inte skapat har bearbetats emellan. Men jag är ingen guru på Net så jag är inte 100% säker. Ideen med ThreadPool kommer från denna artikel om prestanda från MS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
Jag ska ta och läsa mer om Remoting på en gång och se om det kan vara nått. Men om jag använder remoting och implementerar det på ett bra sätt så ska jag kunna hantera minst 300 samtidiga användare?Sv: Distribuerad app, kommunikations metod?
Remoting och prata direkt över tcp skiljer sig knappt alls i prestanda, så den diskussionen känns förlegad... Däremot vinner du en massa på att använda remoting vad gäller utveklingstid osv.. vad du måste göra är ju att skriva ett eget remoting framework annars..
>Mmm... vad jag hade tänkt var att man serialiserar dem till XML så man >får ett rent XML-dokument. Som jag krypterar och sedan skickar.
Att skicka ren xml är mer mängd data än att skicka ett objekt binärt över tråden, så det är inte en förbättring. Ur en skalbarhets och prestanda synpunkt är det sämre, eftersom du får mer tyngd på din tråd. Usebility är defintivt bättre.
>Om jag har förstått rätt så är klassen ThreadPool med dess statiska >metoder ett gränssnitt mot NT-Thread Pool. Provar man att skapa några >trådar så ser man på dess "id nummer" att andra trådar man själv inte >skapat har bearbetats emellan. Men jag är ingen guru på Net så jag är >inte 100% säker. Ideen med ThreadPool kommer från denna artikel om >prestanda från MS:
>http://msdn.microsoft.com/library/default.asp?url=/library/en->us/dndotnet/html/dotnetperftechs.asp
Jättebra om du skall bygga servra, men det du vill göra är ett distribuerat system... COM+ bruakr ofta vara bra att använda vad gäller poolning av objekt och resurser, men om du bara skall hantera requests, behövs inte ens det, inte trådar heller.. Det sköter .net framework av sig själv om du använder remoting. Det är det jag menar när ajg säger att du måste skriva hela remoting frameworket själv... Använder du istället befintlig teknolig så minsakr du utvecklingstiden, men litar du inte på att Microsoft kan göra sitt jobb, skriv hela det själv då ...
>Jag ska ta och läsa mer om Remoting på en gång och se om det kan >vara nått. Men om jag använder remoting och implementerar det på ett >bra sätt så ska jag kunna hantera minst 300 samtidiga användare?
Menar 300 samtidga användare som 300 som ropar på en komponent exakt samtidigt ?? isf tittar du på ett sytem med någon miljon användare på en 8 timmars period, då får du titta på mycket mer än transporten mellan lagrena.
Vad gäller 300 användare / 8 timmars period så pratar vi inte mer än 1-5 samtidga användare .. då räcker defintivt endast remoting till, behöver inte ens titta på cachning eller COM+ (om du inte skall jobba med distribuerad transaktioner över flera datkällor, eller behöver säkerheten). Räcker att utnyttja stored procedures pre-compile möjligheter.
Sv: Distribuerad app, kommunikations metod?
Problemet med krypterad kommunikation eller snarare att datat ska vara krypterat kvarstår tyvärr. Men jag ska fundera vidare på det.Sv: Distribuerad app, kommunikations metod?
Vad är det för protokoll du ska använda dig av? Du skrev bara TCP tidigare.
SSL kanske kan vara en krypteringsmetod att titta på? Den används ju av det mesta idag, http, smtp, pop, imap, ftp osv.
Med SSL så kan du ju både kryptera informationen och autentisera användaren.Sv: Distribuerad app, kommunikations metod?
Sv: Distribuerad app, kommunikations metod?
Sv: Distribuerad app, kommunikations metod?
Sv: Distribuerad app, kommunikations metod?
Nu är ju inte Base64 en kryptering utan en encoding. För att kunna skicka 8-bitars dokument genom 7-bitars mjukvaror.Sv: Distribuerad app, kommunikations metod?
Låter vettigt, men jag är inte säker på TCP kanalen är bästa valet om du har klienter som kommer in via Internet - det är inte många administratörer som är villiga att öppna upp extra portar i brandväggen. Så fundera på att köra över HTTP istället. Eller kanske HTTP externt och TCP internt, beroende på hur fördelningen av användare är.
>Problemet med krypterad kommunikation eller snarare att datat ska vara krypterat kvarstår tyvärr.
Har för mig att det finns ett enkelt exempel på en krypteringssink i Ingo Rammers bok Advanced .NET Remoting.
MSSv: Distribuerad app, kommunikations metod?
Den boken ska jag försöka få tag på.Sv: Distribuerad app, kommunikations metod?
Boken finns här:
http://www.datorbokhandeln.se/search.asp?isbn=0764548166&from=psnu&id=3127