best way to send a byte array

[Trapulo]

Hello,
I need to send to a webservice a parameter that is a string containing an
XML doc. In this xml, a node value came from a byte array (it's an RSA
signature). What is the best way to convert the original byte () value to
the xml and viceversa?

I've tried a lof of way, as encoding.utf8, encoding.unicode, bitconverter,
etc, but the only working solution I found is Convert.XXbase64String:

writer.WriteElementString("ContentSignature",
Convert.ToBase64String(ContentSignature, Base64FormattingOptions.None))
to create the xml node, and then:

out.ContentSignature =
Convert.FromBase64String(data.SelectSingleNode("Co ntentSignature").Value)

to decode the xml and recreate a byte array.

The problem is that base64 expands a lot the data (about 30% in my tests),
so I'd like to know if there is an other way I can have this goal without
increase my data a lot (I may tarnsfer them over GPRS)...

thanks

[Steven Cheng[MSFT]]

Hello Trapulo,

I think the BASE64 encoding is the reasonable approach for your scenario.
Generally, there're two common encoding methods for concerting between
string text and binary byte array, base64 and hex string.

For base64 encoding, it conform to the standard base64 encoding rules and
..net framework's Convert class implement this according to the standard.

For Hex encoding, that means we use two hex char(ascii char) to represent a
byte in string, thus, hex encoding will make the encoded string lengh twice
as the original byte stream.

As for the large message size after text encoding problem you suffer here,
I think you may consider adding some compression process against the soap
message or partially on some certain fragment. There are some articles
describing use zip components to compress webservice text content:

#Web Service Compression with .NET CF
http://blogs.msdn.com/windowsmobile/...03/345934.aspx

#Web Service Compression
http://weblogs.asp.net/pglavich/arch.../24/62475.aspx

Here are some available 3rd party zip component librarires:

#commercial, shareware, freeware, and open source zip components
http://datacompression.info/Zip.shtml

BTW, as for those encoding like Utf-8 or Unicode... they're specific to
text encoding for different charset in multilingual environment, not
specific to binary text converting. Also, are you directly pass the string
(contain XML data) as parameter (or return type) of webservice methods? If
so, this is not recommended and the best practice for transfering xml data
in webservice method is to use the .net framework XmlDocument class. See
below article:

#Rant: Don't return XML in string variables!
http://blogs.msdn.com/mpowell/archiv...12/130637.aspx

Hope this helps. Please let me know if there is anything else you wonder.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Steven Cheng[MSFT]]

Hi Trapulo,

Does the information in my last reply helps a littitle? if there is
anything else we can help, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[Trapulo]

"Steven Cheng[MSFT]" <st*****@online.microsoft.comwrote in message
news:P4**************@TK2MSFTNGXA01.phx.gbl...

Hello Trapulo,

I think the BASE64 encoding is the reasonable approach for your scenario.
Generally, there're two common encoding methods for concerting between
string text and binary byte array, base64 and hex string.

For base64 encoding, it conform to the standard base64 encoding rules and
net framework's Convert class implement this according to the standard.

For Hex encoding, that means we use two hex char(ascii char) to represent
a
byte in string, thus, hex encoding will make the encoded string lengh
twice
as the original byte stream.

Ok, thanks. So I'll use only base64 every time I need to "serialize" a byte
array and I cannot use a binary channel and protocol.

As for the large message size after text encoding problem you suffer here,
I think you may consider adding some compression process against the soap
message or partially on some certain fragment.

You read in my mind :)
My next problem was to compress the SOAP message, or at least the bigger
parameter I use to load/unload some data. I've previously searched some
ideas, and I think the best solution will be to add a compression to all
SOAP payload using the open source sharpdevelop compression library. I had a
lot of trouble working with that library in CF (why CF has a simple
compression library in standard framework, and nothing in CF? sigh..), and
some strange runtime errors trying to work with code samples that add
compression to net SOAP pipeline. So I have archived the problem for a
while, but now it's time to solve it.

There are some articles
describing use zip components to compress webservice text content:

#Web Service Compression with .NET CF
http://blogs.msdn.com/windowsmobile/...03/345934.aspx

#Web Service Compression
http://weblogs.asp.net/pglavich/arch.../24/62475.aspx

Here are some available 3rd party zip component librarires:

#commercial, shareware, freeware, and open source zip components
http://datacompression.info/Zip.shtml

BTW, as for those encoding like Utf-8 or Unicode... they're specific to
text encoding for different charset in multilingual environment, not
specific to binary text converting.

Thank you for this addendum. In fact I suspected this, but I was thinking
that maybe every enconding uses different schemas and bytes to manage every
char, so maybe using a different encoding will "stream a string" in a
different byte sequence.

Also, are you directly pass the string
(contain XML data) as parameter (or return type) of webservice methods?

Yes

If
so, this is not recommended and the best practice for transfering xml data
in webservice method is to use the .net framework XmlDocument class. See
below article:

#Rant: Don't return XML in string variables!
http://blogs.msdn.com/mpowell/archiv...12/130637.aspx

That's interesting, thank you. The only problem implementing it is that now
I have a classes structure that creates the xml data passing same
XmlTextWriter to each involved objects, so I'll need to write the xml into a
string variable and then create an XmlDocument and load data in, and I think
that performance will a lot (XmlDoc may check xml structure). Or I may
change all application structure.. Anyway, I will find a solution.
Thanks you for your assistance.

[Steven Cheng[MSFT]]

Thanks for the followup Trapulo,

I haven't inspected deep against those compression library, it is likely
that some ones haven't been designed and tested against CF environment
originally. You'll need to perform more tests before using them.

For the following questions:

===========================================
In fact I suspected this, but I was thinking
that maybe every enconding uses different schemas and bytes to manage every
char, so maybe using a different encoding will "stream a string" in a
different byte sequence.
============================================

I think the "encoding" you mentioned here should means all those Unicode
encodings (such as UTF-16, UTF-8...), because only unicode encoding can
ensure that all the characters from ASCII char or wide chars(in east
asia.... ) can be correctly represented. And you're right, different
encoding define a different character ---- binary code mapping table. The
same char will have different binary code when using different encoding to
convert them.

As always, if you meet any further questions, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[Trapulo]

"Steven Cheng[MSFT]" <st*****@online.microsoft.comwrote in message
news:MW**************@TK2MSFTNGXA01.phx.gbl...

Thanks for the followup Trapulo,

I haven't inspected deep against those compression library, it is likely
that some ones haven't been designed and tested against CF environment
originally. You'll need to perform more tests before using them.

I've found a working sample, where the project has been changed a little and
can compile to CF. I've implemented a SOAP compression both on server and
client, and it's working very well. I think I can save a lot of money on
GPRS bandwith :)

For the following questions:

===========================================
In fact I suspected this, but I was thinking
that maybe every enconding uses different schemas and bytes to manage
every
char, so maybe using a different encoding will "stream a string" in a
different byte sequence.
============================================

I think the "encoding" you mentioned here should means all those Unicode
encodings (such as UTF-16, UTF-8...), because only unicode encoding can
ensure that all the characters from ASCII char or wide chars(in east
asia.... ) can be correctly represented. And you're right, different
encoding define a different character ---- binary code mapping table.
The
same char will have different binary code when using different encoding to
convert them.

Thank you, this can explain better how this stuffs work and my ideas about
them.

bye