Direkt Internetmeddelandeinkapsling

Direct Internet Message Encapsulation (DIME) var en internetstandard som Microsoft föreslagit i början av 2000-talet för strömning av binär och annan inkapslad data över Internet.

Enligt IETF:s webbplats har standarden dragits tillbaka och har aldrig blivit RFC- status. Microsoft rekommenderade dock en gång DIME för att överföra filer via webbtjänster . Det användes också i Java EE , men skillnader i implementeringen av protokollet gjorde det svårt. ^{[ citat behövs ]}

Den första versionen lämnades till IETF i november 2001; den senaste uppdateringen lämnades in i juni 2002. I december 2003 hade DIME förlorat, i konkurrens med Message Transmission Optimization Mechanism och SOAP with Attachments . Microsoft beskriver nu DIME som "ersatt av SOAP Message Transmission Optimization Mechanism (MTOM)-specifikationen"

Standarden var tänkt att vara en förbättrad version av MIME . Speciellt en svårighet med MIME är att varje meddelande måste kodas som text och att dess avsnitt är åtskilda av en avgränsare som anges i meddelandehuvudet. Detta innebär att hela dataströmmen måste vara känd för avsändaren innan kommunikationen påbörjas, för att välja en separator som inte förekommer i datan. Detta är inte användbart om hela strömmen inte är tillgänglig när kommunikationen initieras, eller när det är dyrt att söka efter det. DIME är mer inriktat på streaming, vilket gör att till exempel en mottagare kan bearbeta delar av meddelandet när de kommer utan att behöva vänta på hela meddelandet.

Kritik

Problem med HTTP

DIME definierades som överföringsformatet vid datalänklagret i OSI -modellen även om det vanligtvis överfördes över HTTP . En svårighet här var att det kunde bilda ett HTTP-meddelande av i princip vilken storlek som helst (gränsen är storleksinformationen för varje bit, som var 32 bitar så 1 gigabit). Många HTTP-mottagare var inte vana vid så stora meddelanden som detta, och om de buffrade meddelanden skulle de helt enkelt misslyckas, på grund av att programvaran förväntade sig ett kort meddelande, men istället fick ett långt. Dessutom, om HTTP-mottagaren var säkrad, skulle den skicka tillbaka ett utmaningsmeddelande (400-kod) till avsändaren vid mottagande av meddelandet. Eftersom HTTP är anslutningslöst, skulle den då helt förlora den möjligen enorma mängden data som hade skickats till den, bara för att acceptera eller förneka utmaningen. Svaret på utmaningen skulle naturligtvis kunna lyckas, på bekostnad av att skicka data två gånger, vilket om det vore enormt snarare motverkar sin poäng.

I den alternativa lösningen fastställs kriterierna för en lyckad utmaning (t.ex. ett användarnamn och lösenord) utanför bandet, så det kan skickas med meddelandet första gången och inte ta emot en utmaning (biprodukten av den anslutningslösa HTTP-protokollet är att eftersom varje meddelande behandlas individuellt måste alla meddelanden framgångsrikt kunna inkludera sitt utmaningssvar).

DIME var extremt snabb jämfört med praktiska tillämpningar av andra protokoll. Eftersom datan var binär snarare än till exempel Base64- kodad, var den relativt kompakt, och chunking- och paketmetoderna inbyggda i protokollet innebar att den kunde streamas och läsas av en lämplig mottagare innan hela meddelandet hade lästs.

Problem på nätverkslagret

Eftersom DIME definierades vid datalänklagret, var det möjligt att kapsla in ett DIME-meddelande i ett annat DIME-meddelande. Detta skulle inte hjälpa alls för komprimeringsändamål men var ibland användbart för att kringgå nätverksinfrastruktur som routrar i nätverkslagret av OS-modellen, som annars skulle blockera den inkapslade trafiken (som är binär kan de behandla den med misstänksamhet). Med det sagt kan andra protokoll som MIME lika gärna drabbas av sådana. Eftersom DIME vanligtvis användes mellan välbetrodda klienter, kunde en specifik port öppnas på routern för det uttryckliga syftet att skicka och ta emot DIME-trafik. Detta undergrävde inte säkerhetsaspekterna, eftersom utmaningen fortfarande skulle inträffa, bara att den accepterade att binär trafik var normen på den porten och inte gav många falska positiva resultat .

Se även

SOAP med bilagor

externa länkar