Har en liten fundering. Finns det nåt hyfsat enkelt sätt att få igång en säker överföring mellan en klient och server? Det största problemet jag har är att servern är skriven i Java och klienten i C#. Jag behöver alltså nånting som fungerar på båda och webservices är inget alternativ. Har tittat lite på SSL och det kanske kan vara en lösning men jag tänkte lyssna om det är nån som har nån annan uppfattning. Det verkar som om .net 2.0 kommer ha stöd för SSL i sockets men frågan är ju om man pallar att vänta eller om man ska gå på nån tredje parts grej?

Nån som har några förslag?

Varför inte webservice? käns som rätt verktyg för jobbet.
Annars kan du ju bara posta in vad som helst i binärt eller txt format via HTTPS om du föredrar det.

Webservice är inget alternativ eftersom overheaden är för stor. Vi har ett eget xml-baserat protokoll istället. Hur skulle man använda https? Om man skulle kunna använda https varför behöver man då ssl-sockets? Vi snackar ju ingen web-app utan hardcore server-client via tcp.

Det finns tredjepartssaker; http://www.google.se/search?hs=Od4&hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial_s&q=c%23+ssl&btnG=Search = http://www.mentalis.org/soft/projects/ssocket/ (som för övrigt är välkänd inom .net och ssl)

Johan, https är http genom SSL (secure sockets layer).

Varför säger du att overheaden blir för stor? Det håller jag inte med om. Om du redan har XML så har du redan det problem med overhead som XML introducerar. Att wrappa meddelandet i SOAP och följa standarder kostar inte så många extra bytes, det är bara snyggt att göra så.

Du kan förstås bygga din helt egna PGP-baserade krypteringslösning genom TCP och uppfinna ett eget protokoll oxå men du uppfinner hjulet igen utan att vinna något på det. Pardon my french, men det är mer korkat än hardcore ;-)

"frågan är ju om man pallar att vänta eller om man ska gå på nån tredje parts grej? "

Tja det beror ju på när du skall vara färdig? .NET 2.0 har release datum om en månda, men redan nu kan du ju börja bygga din applikation i Beta2 eller RC1. Så om du har lanseringe senare än November så behöver du ju inte vänta, bara sätt igång...

För din del så kanske du skall titta lite på Indigo, om din lanseringen av produktetn inte är under 2006 utan senare (har för mig att Indgo kommer sommar/höst 2006) vilket kommer att göra .NET koden mycket enklare att skriva, tyvärr hjälper det inte så mycket i JAVA, men så är det när alla inte förstått vad som är bäst :)

- M

>Varför säger du att overheaden blir för stor? Det håller jag inte med om. Om du redan har XML så har du redan det problem med overhead som XML introducerar. Att wrappa meddelandet i SOAP och följa standarder kostar inte så många extra bytes, det är bara snyggt att göra så.

Nej, eftersom vårt xml protokoll är otroligt mycket mer slimmat så tjänar man otroligt mycket. Visst om man har enkla grejer så kan jag tänka mig att webservices är en bra sak men så fort du skall ha en struktur som är lite mer avancerad och ha en trafik som är på ett par kb så är det inte speciellt optimalt med SOAP. Det är iallafall våra erfarenheter.

Kan man utnyttja http protokollet för att köra vilken kommunikation som helst eller finns det några begränsningar (prestanda etc)? Om inte, varför introducerar man en secure socket i nästa version?


Oskar: har kollat lite på mentalis och det skulle nog funka. Vi får ta oss en funderare...

<b>Nej, eftersom vårt xml protokoll är otroligt mycket mer slimmat så tjänar man otroligt mycket. </b>


Jag tror dig inte ;)
Du kan ju använda din "otroligt slimmade" XML i SOAP-bodyn.
Det enda extra overhead du får då är SOAP-headern, några hundra bytes bara. Att du skulle spara "otroligt" mycket på att inte ta med det, verkar inte rimligt.
Om vi inte pratar "realtidssystem" men oerhörda prestandakrav.
Men om det är så, ska du snarare välja bort XML än SOAP.


<b>Visst om man har enkla grejer så kan jag tänka mig att webservices är en bra sak men så fort du skall ha en struktur som är lite mer avancerad och ha en trafik som är på ett par kb så är det inte speciellt optimalt med SOAP. Det är iallafall våra erfarenheter.</b>


Du kan ha precis så avancerad struktur du vill i din XML som finns i din SOAP-body.



<b>Kan man utnyttja http protokollet för att köra vilken kommunikation som helst eller finns det några begränsningar (prestanda etc)? </b>


Nja inte vad som helst. För t ex spel och mp3-streams kör man ju UDP men det är ju en helt annan historia, du kan ju inte skicka XML över UDP ändå.
HTTP är slimmat och snabbt. De program (webservers osv) är i regel oerhört optimerade pga de krav som systemen fått på sig genom WWW. Det är en öppen standard som har implementerats på snart alla tänkbara plattformar. Det finns ingen anledning att uppfinna något eget.


<b>Om inte, varför introducerar man en secure socket i nästa version?</b>

Jag gissar att man vill underlätta för utvecklare att implementera SSL för andra protokoll än HTTP. T.ex. SMTP och POP3.

Du får tro vad du vill, men den erfarenheten jag har är iallafall att en webservice inte ens är i närheten av samma prestanda som om du skulle prata med en socket direkt på andra sidan. Jag fattar inte varför webserbvices alltid försvaras med näbbar och klor?!? De fyller sin funktion men det är inte optimalt att använda dem till allt. Visst har du verksamhetssystem som en massa olika apps pratar med - fine då är alternativet att inte prata alls.

"Du får tro vad du vill, men den erfarenheten jag har är iallafall att en webservice inte ens är i närheten av samma prestanda som om du skulle prata med en socket direkt på andra sidan. "

Det beror ju oftast inte på protokollet HTTP utan mer på att du serializerar objekt till XML, det är där prestandaförlusten ligger.

Det finns dock lite andra problem med WebService (iallafall i .NET) som har med trådhanteringen att göra, vilket gör det mer logiskt att implementera en egen väg via sockets, om man nu inte vill att ens klienter skall ha en egen "callback webservices", vilket så fall kräver att de har IIS:en installerad

- M

>Det beror ju oftast inte på protokollet HTTP utan mer på att du serializerar objekt till XML, det är där prestandaförlusten ligger.

Nej, precis. Det är det jag försöker säga men inte lyckas. I mina ögon så kan man inte använda nåt standard med webservices om man vill ha upp prestandan, och om webservicen dessutom inte direkt tillför nåt till systemet så varför använda den tekniken när det finns andra som är snabbare och mer passande för lösningen? I mina ögon är det underordnat vilken teknik eller arkitektur jag använder huvudsaken är att problemet blir löst på det mest optimala sättet.

Nåja, jag har satt det som löst eftersom svaren jag fick var ungefär som jag antog i början. Ska kolla vidare men förmodligen blir det att avvakta till 2.0.

Jag försvarar inget med näbbar och klor. Jag rekommenderar bara att du i det här fallet funderar på att lösa det med HTTP och SOAP. Jag vet av erfarenhet att det fungerar bra och att det i 9 fall av 10 är tillräckligt bra. Speciellt eftersom du vill ha SSL, då finns det redan genom HTTPS. Det blir ganska smidigt att implementera det. Tid är pengar, du vet..
HTTP pratar också med TCP sockets, under ytan. Eller vad tror du händer där egentligen? Inte så vansinnigt mycket mer än vad du ändå måste göra i ditt egna applikationsprotokoll, som du nu ska uppfinna och konstruera... Och så måste du implementera SSL på ditt egna sätt. Jag tror inte du kommer att tjäna något på det, men "tro vad du vill"..

Ola, jag tror du missuppfattar det hela. Jag har redan en lösning som fungerar. Det är bara det att om nån får för sig att börja sniffa paket så ser de ju vad som skickas eftersom det inte är någon kryptering eller säkerhet på överföringen. Jag behöver väl inte alls implementera SSL på mitt lilla sätt, jag kan ju precis som du föreslagit använda https eller vänta på secure server socket i 2.0. Den initiala frågan var ju egentligen om det fanns någon annan teknik som man kan använda istället för SSL som jag redan kollat lite på.

Det var liksom den här diskussionen jag ville undvika genom att jag skrev att jag inte ville använda webservices. Nåja, skit samma. Jag ska fundera vidare och testa lite så får vi väl se vad det blir

Ja du kan använda https, och då har du i princip en webservice (som du inte ville ha...?)
(du skickar din egen XML via https)
Detta blir per definition en webservice, som inte följer standarden SOAP.

Det är väl OK om det för all framtid bara handlar om din egna klient och din egna server.
Fördelen med att göra det enligt SOAP är ju att du i framtiden väldigt enkelt kan integrera med andra system eftersom fler och fler pratar SOAP i dag. och det kostar INTE "otroligt mycket mer" prestanda att du wrappar din XML i SOAP. Jag förstår inte varför det irriterar dig att jag ger dig mina tips, du behöver inte ta till dig det om du inte vill.

men det är ju en väldig overhead att gå mot en webserver.

en egen socket skickar bara det som behövs , en webserver ska starta sessioner , allokera trådar som hanterar anropet och as far as i know , så disconnectar man alltid från servern så det blir connect / disconnect hela tiden vilket tillför ytterligare massor av overhead.

(men jag kan vara helt fel ute, det kanske går att hålla kopplingen vid liv i http oxo , eller om det enns är något Johan behöver)

Hur som jag har inte heller några bra erfarenheter att gå mot webserver istället för mot en egen server

//Roger

Nej, i HTTP 1.1 ska kopplingen hållas öppen default annars genom att du sätter Keep-Alive.

Sessioner eller ej bestämmer applikationen. I en asp.net webservice är det bara att stänga av sessioner i web.config. Vilket man naturligtvis alltid skall göra om man inte behöver sessioner.