MessageSize does matter

WCF is ingericht in het versturen en ontvangen van berichten via
verschillende soorten bindingen. De vraag- en antwoordberichten kunnen hierbij
zelfs vele megabytes groot zijn. De maximale grootte wordt voornamelijk bepaald door het type binding, zo heeft MSMQ een limiet van vier megabytes. Maar standaard is de grootte veel beperkter ingesteld.

Size DOES matter
Deze week liepen we tegen een dergelijke grens aan, maar:

1. Het was de grootte van het aanvraagbericht welke problemen gaf, niet het
antwoord

2. We gebruiken wsHTTP

We wilden namelijk een grote lijst met ruwe data laten verwerken. Dit
gebeurt stateless, de aanvraag opdelen in kleine stukken is geen optie. We
kregen namelijk al problemen bij het versturen vanaf iets meer dan acht KB.

System.ServiceModel.FaultException`1 was unhandled
Message=”The formatter threw an exception while trying to deserialize
the message: There was an error while trying to deserialize parameter
http://tempuri.org/:composite. The InnerException message was ‘There was an
error deserializing the object of type CompositeType. The maximum string content
length quota (8192) has been exceeded while reading XML data. This quota may be
increased by changing the MaxStringContentLength property on the
XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1,
position 9020.’.  Please see InnerException for more details.”

Bij meer dan negentig KB kregen we de volgende melding:

System.ServiceModel.ProtocolException was unhandled
Message=”The remote server returned an unexpected response: (400) Bad
Request.”

Beide meldingen komen voort uit de standaard instellingen van de binding.
Maar wat zijn die instellingen dan? Waar kan je die vinden?

Ik heb hiervoor een testsituatie gebouwd: een WCF webservice host wordt
aangeroepen door een console applicatie. De host ondersteunt  één methode welke een string accepteert en een string retourneert. De methode geeft een string terug met de inhoud van de  tien keer de parameter achter elkaar. Als je de
cliëntreferentie laat genereren, kijk dan eens in de app.config van de cliënt.
Daar is een complete bindingconfiguratie aan toegevoegd:


<bindings>

  <wsHttpBinding>

    <binding name="WSHttpBinding_IService" ...

    </binding>

  </wsHttpBinding>

</bindings>

Deze bindingconfiguratie wordt aan het ABC (adres, binding en contract)
toegevoegd via een extra attribuut:


<endpoint address="http://localhost:1234/WCFService/Service.svc"
          binding="wsHttpBinding"
          bindingConfiguration="WSHttpBinding_IService"
          contract="ServiceReference.IService"
          name="WSHttpBinding_IService">

Kijk nu eens naar de host web.config. Deze is veel eenvoudiger:


  <endpoint address="" binding="wsHttpBinding" contract="IService" >

Op de host is de binding blijkbaar al standaard geconfigureerd en deze
settings zijn in de cliënt netjes herhaald en uitgeschreven. Let wel: deze
instellingen moeten wel aan beide kanten gelijk aan elkaar gemaakt worden.

Tussen de binding-instellingen staat ook de al eerder genoemde instelling
maxStringContentLength. Als je deze in de app.config aanpast
zal er niet veel gebeuren… Zoals hiervoor al gezegd, cliënt en host moeten op
elkaar aansluiten. Het is dus zaak de aangepaste binding configuratie ook de
host door te voeren. Kopieer dus de <bindings>
instellingen uit de app.config gewoon door naar de web.config. Vergeet
niet in het EndPoint element het attribuut
bindingConfiguration=”WSHttpBinding_IService” op te nemen.

Dit helpt in eerste instantie wel. Maar met wat grotere berichten krijgen we
al snel de melding:

System.ServiceModel.CommunicationException was unhandled
  Message=”The maximum message size quota for incoming messages
(65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize
property on the appropriate binding element.”

Door dus ook de MaxReceivedMessageSize aan beide zijden te
vergroten wordt het mogelijk om grote berichten te versturen, en ontvangen. Bij
veel voorbeelden op het internet worden gewoon alle instellingen verminkt, ik
heb hier willen aantonen dat met goed lezen en enkele eenvoudige aanpassingen de problemen al opgelost kunnen worden.

Het is hierbij aardig om te weten dat ‘recieve’ altijd vanuit de context van
de cliënt of de host geldt. De MaxReceivedMessageSize in de
app.config geldt bij de cliënt dus voor de berichten vanaf de host richting de
cliënt, nav. een aanvraag.

Kijk nog eens naar de meldingen bovenaan in deze blog.  De eerste
FaultException werd gegooid omdat de cliënt een te lang antwoord moest ontvangen (tien maal de aangeboden tekst van acht KB). De http Error 400 Bad
Request was vrijwel zeker dezelfde fout aan de host kant door de verminkte
request (te lange parameter). Helaas wordt dit als een Bad Request teruggegooid, de host neemt het bericht gewoon niet in ontvangst zodra er teveel data ontvangen wordt.

Kijk voor meer informatie over de verschillende binding configuraties hier zoals die van de wsHttp.

Advertenties

Ga lekker taggen met Microsoft Tag!

De GSM is allang geen belijzer meer. Het wordt steeds meer een persoonlijke gereedschapkist.

Hoewel de meeste bellers het toestel niet noemenswaardig uitbreiden met nieuwe toepassing (alleen een nieuw kleuren thema, ringtones, een nieuwe skin of frutsels er aan) is het een walhalla voor de geek en buttonfreak.

Zo kwam ik gisteren op het tooltje Microsoft Tag uit. Dit is een simpele applicatie welke ‘barcodes’ van internetpagina’s, beeldschermen, kranten en andere dodeboom-media kan uitlezen en kan omzetten naar een website, vrije tekst, telefoonnummer of een Outlook contact.

Microsoft Tag op een Nokia

Waarom? Omdat het kan en gemak dient de mens… Dit wordt mogelijk gemaakt
door een simpel programma welke de GSM camera uitleest en een barcode probeert te herkennen.

Surf naar http://gettag.mobi/ (dit kan ook prima vanaf je mobiel). En vrijwel zeker is er ook voor jouw toestel een download beschikbaar. Na installatie kan je direct aan de gang met het aangeboden voorbeeld. En zowaar, mijn GSM pakte zonder probleem de barcode op en reageerde er correct op door de browser te openen en naar de site achter de barcode te surfen.

Het geheim is een combinatie van redelijk recht-toe-recht-aan beeldherkenning
wat een gemiddelde GSM ondanks de beperkte kwaliteit van de camera en beperkte processorcapaciteit toch best kan verhapstukken, en een hele slimme ‘barcode’.

Deze barcode is vierkant, is in twee richtingen (2D) opgebouwd met kleine
gekleurde driehoekjes met scheidslijnen voor een verhoogd contrast. Dit is
voldoende voor 3500 karakters per inch-in-het-kwadraad.

Leuk, maar wat kun je er mee? Nou, ehmm… De technologie is nieuw en het
aantal tag is nog beperkt. Nu is het nog gratis om tags aan te maken, maar bij
voldoende populariteit kan Microsoft er wel eens geld voor gaan vragen. Ik denk
dat het een spin-off van de nieuw te openen Microsoft webstore (Windows Marketplace for Mobile) is.

Maar wacht eens, kun je ook zelf tags maken? Ja. Ga hiervoor naar hier (meldt je aan via je Microsoft Live Messenger account) en wordt overdonderd door een site van één (1) pagina’s, en nog bijna helemaal leeg ook. Hier kun je jouw tags aanmaken, wijzigen, verwijderen en de barcodes exporteren naar verschillende formaten. Tevens is het mogelijk om het met een fraai grafiekje per tag het aantal keren gebruik per dag te monitoren.

Als je kiest om een tag aan te maken moet je enkele simpele gegevens
invullen:

Tag Title Een omschrijving voor in het onderhoudsscherm
Tag Type Kies hier voor URL, Free Text, vCard, Dialer
Tag Notes Geen een optionele beschrijving op over de tag als je dat wenst
Start Date (GMT) Startdatum voor het openstellen van de tag
End Date (GMT) Optionele einddatum

Afhankelijk van het type kan nog meer informatie benodigd zijn. bij invoer is
soms ook een wachtwoordingave mogelijk.

Iedere tag is daarna in 5 versies (van simpel tot compleet met download
instructie) te verkrijgen. De tag wordt dan ter download aangeboden als PDF, WMF en XPS. Waarom is het niet direct als GIF of PNG beschikbaar?

Hieronder heb ik een aantal voorbeelden geplaatst. Ben je geïnteresseerd
geraakt? Speel er dan eens mee en laat je verrassen over de mogelijkheden! Ik
zie de staafbalkjes wel groeien 🙂

Microsoft Tag voorbeeld 1

Microsoft Tag voorbeeld 2

Microsoft Tag voorbeeld 3

Microsoft Tag voorbeeld 4

Tenslotte. Ik zie hier zelf wel een aardig speeltje in. Als actieve Geocacher moet
het een hele leuke sport zijn om robuste en weerbestandige stickers te gaan
plaatsen op de wildste plekjes. En met een simpele scan heb je er weer ééntje
afgewerkt. Dat is nog leuker dan voetbalplaatjes sparen.