Re: HttpWebRequest in .NET CF 2.0 - Sent XML File over 34K Corrupt

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Customers are using Broadband Ethernet Networks for access to the Internet.
No telephony is involved at all; GPRS, CDMA or otherwise.

Also, I am not controlling packet sizes, ack/naks or checksums. I am simply
using the HttpWebRequest/HttpWebResponse objects for communications with the
host server. I create a SOAP Request on the mobile device, package it into a
single String (that gets converted to a byte array using UTF8Encoding) then
I simply get the request stream of the HttpWebRequest object and call
RequestStream.Write(bytes, 0, bytes.length). Also, as previously noted, I
have sent these SOAP Requests with strings as large as 125K in size without
issue and I cannot reproduce the problem that the very limited number of
customers are seeing (2-3 out of 70+). The data is always valid before I
send it, because I perform an XmlDocument.LoadXml(SoapString) within a
Try...Catch and it would hit the Catch if the XML Tag Structure was invalid
but it never hits the Catch statement (I have tested this functionality by
purposely making the XML Structure invalid by placing missing tags and
invalid data within the SOAP Request and the Catch does get called!)
However, the overall SOAP Request can end up corrupted on the server side
and I do not have the ability to request that the mobile device resend the
SOAP Request at this time.
Thanks for the advice though Simon!!

Questions still unanswered so far (as of 11/15/2007):
1) Does anyone know if the bug in .NET CF 1.1 regarding the use
HttpWebRequest over HTTPS is still an issue in .NET CF 2.0 or can I
disregard the workaround for that bug?
2) Does anyone know if the Microsoft Article (ID 831578) regarding "Memory
Leak When SSL and Client Certificates are Used With the HttpWebRequest
Object" only pertains to the Desktop .NET 2.0 Framework or does it also
include .NET CF 2.0?
Again, thank you for your time,
Greg Hellem


"Simon Hart [MVP]" <srhartone@xxxxxxxxx> wrote in message
news:5354B348-FF15-4A9E-A758-4AF290F1EC75@xxxxxxxxxxxxxxxx
That does look a bit dodgy. Over what network was this corrupted? If GPRS
it
could be the carrier not handling the encryption/decryption correctly. If
so
contact the carrier. I would be inclined to reduce those packet sizes if
at
all possible. Do you have any sort of status tracking or checksum? so if
the
message appears corrupt, you simply do a resend.

--
Simon Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com


"Greg Hellem" wrote:

Not easily accomplished, since the same server-side code used to receive
mobile SOAP requests are also used for non-mobile SOAP requests and it
would
be a major modification to differentiate between the two. I was hoping
someone would recognize a known bug in .NET CF...
But thanks for the idea!
- Greg

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:OMjBiliJIHA.4684@xxxxxxxxxxxxxxxxxxxxxxx
I'd be inclined to add a CRC to the packet and validate that what I
received is what the server sent. If the CRC fails, resend.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com


"Greg Hellem" <ghellem@xxxxxxxxxxx> wrote in message
news:13jjnahr9vj6ga1@xxxxxxxxxxxxxxxxxxxxx
I have a .NET CF 2.0 Mobile Application that sends "collected data" to
a
HTTPS Server (running Apache under Windows 2000) and the XML file
(SOAP)
containing the collected data "occasionally" appears corrupted on the
server side, but only when the XML file is greater than 34K in size,
and
cannot be properly parsed as an XML Document due to missing / corrupt
XML
Tags. I say "occasionally" because I cannot reproduce this error myself
and only a few of our customers (2-3 out of 70) using the mobile
application have experienced this situation. The XML file is never
corrupt
as long as it is under 34K in size.

In an attempt to reproduce this error I have sent "collected data"
files
as large as 125K without any XML errors and did so using various
Internet
Connections, i.e. using our corporate intranet, the Internet via ADSL
from my home and using ActiveSync running on a Desktop Machine
connected
to our intranet and the Internet. I have NEVER been able to reproduce
this error which led me to believe that the problem was due to
hardware
failures of the mobile device itself or the customers network, but
after
extensive research and testing this does not appear to be the problem
either. Also, the "collected data" itself does not contain any
characters
that would violate the XML standard and I went so far as to add some
code
to the mobile application that validates the XML Structure prior to
sending the data to the host server and the structure is always
validated
before sending but arrives at the host server corrupted!! I am
assuming
that the HTTPS / TCP/IP protocols will handle corrupt packets via the
packet checksum and request the packet again, so I don't think data is
being corrupted during its trip to the host server but instead is
actually corrupt when being transmitted from the mobile device itself,
hence the packet checksums are always correct. The mobile device is a
Symbol MC3090 running WinCE 5.0 and Symbol (now Motorola) has no
mention
of any "data corruption" within their knowledgebase regarding these
devices.

I have read the Microsoft Article (ID 831578) regarding "Memory Leak
When
SSL and Client Certificates are Used With the HttpWebRequest Object"
but
am unsure if this applies to the .NET CF 2.0. We are using HTTPS / SSL
and I am using the standard example given for the
LocalCertificatePolicy.CheckValidationResult to eliminate certificate
problems such as mismatched certificate and machine names but I do not
ignore an invalid certificate.

Originally I was using .NET CF 1.1 when I created this application and
ran into a .NET CF bug regarding the use the HttpWebRequest class
over
HTTPS whereby the workaround was to set AllowWriteStreamBuffering =
True
and to not specify the ContentLength property. Even though the project
has been upgraded to .NET CF 2.0 I am still abiding by the workaround
for
the .NET CF 1.1 bug. Is this still an issue in .NET CF 2.0?

An example of the corrupted xml data: (closing tag of
</ItemEnterpriseName> is corrupt and opening <ItemName> tag is missing
along with the data itself)
<Name>DEFAULT</Name>
<ItemEnterpriseName>Comtech Data</ItemEnterpriseNa4A</ItemName>
<SiteEnterpriseName>Comtech Data</SiteEnterpriseName>
... data continues ...

The data should have appeared as:
<Name>DEFAULT</Name>
<ItemEnterpriseName>Comtech Data</ItemEnterpriseName>
<ItemName>IC/SO-NC7SBU3157</ItemName>
<SiteEnterpriseName>Comtech Data</SiteEnterpriseName>
... data continues ...

Any assistance in the matter would be tremendously appreciated!!!
Thank you,
Greg Hellem








.



Relevant Pages

  • Re: HttpWebRequest in .NET CF 2.0 - Sent XML File over 34K Corrupted
    ... I'd be inclined to add a CRC to the packet and validate that what I received ... is what the server sent. ... cannot be properly parsed as an XML Document due to missing / corrupt XML ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: HttpWebRequest in .NET CF 2.0 - Sent XML File over 34K Corrupted
    ... HttpWebRequest over HTTPS is still an issue in .NET CF 2.0 or can I ... Leak When SSL and Client Certificates are Used With the HttpWebRequest ... cannot be properly parsed as an XML Document due to missing / corrupt XML ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Lost my newsgroups
    ... This the more for XML, ... Xnews is able to load old headers and articles. ... the file will be corrupt. ... next time you post a "GNU/Linux is better then Windows ...
    (alt.internet.search-engines)
  • Re: Wireless TCP aborts
    ... rsync: connection unexpectedly closed ... ... and then the rsync session is dead. ... It seems odd that a single corrupt packet would terminate the TCP ...
    (freebsd-current)
  • HttpWebRequest in .NET CF 2.0 - Sent XML File over 34K Corrupted
    ... containing the collected data "occasionally" appears corrupted on the server ... properly parsed as an XML Document due to missing / corrupt XML Tags. ... mobile device itself or the customers network, ...
    (microsoft.public.dotnet.framework.compactframework)