|
Home > Archive > Unix Programming > October 2004 > Client-Server communication using a XML protocol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Client-Server communication using a XML protocol
|
|
|
| Hi,
I am trying to write a client handler for communication between a
client and a server based on a predifined XML protocol. The protocol
is already defined , all I am looking for is a way for me to send and
recieve messages which would be XML based. I am looking to use Java
..Can someone help me with this .
Thanks
| |
| Måns Rullgård 2004-10-19, 5:51 pm |
| raj20013@yahoo.co.in (Raj) writes:
> Hi,
>
> I am trying to write a client handler for communication between a
> client and a server based on a predifined XML protocol. The protocol
> is already defined , all I am looking for is a way for me to send and
> recieve messages which would be XML based. I am looking to use Java
> .Can someone help me with this .
XML is a markup language, not a protocol. Search google groups for
xml and my name for reasons not to use it.
--
Måns Rullgård
mru@mru.ath.cx
| |
| joe@invalid.address 2004-10-19, 5:51 pm |
| raj20013@yahoo.co.in (Raj) writes:
> I am trying to write a client handler for communication between a
> client and a server based on a predifined XML protocol. The protocol
> is already defined , all I am looking for is a way for me to send
> and recieve messages which would be XML based. I am looking to use
> Java .Can someone help me with this .
There are classes for this available at java.sun.com.
However, as Mans suggested, if you can get out of using XML you'll
probably be better off with another protocol, unless you're selling
bandwidth or cpu :-)
Joe
--
Nothing cures like time and love
- Laura Nyro
| |
| Barry Margolin 2004-10-20, 7:51 am |
| In article <yw1xis96ebew.fsf@ford.guide>,
Måns Rullgård <mru@mru.ath.cx> wrote:
> raj20013@yahoo.co.in (Raj) writes:
>
>
> XML is a markup language, not a protocol. Search google groups for
> xml and my name for reasons not to use it.
If the specification of the application protocol says that the data is
encoded as XML markup, then it's effectively part of the protocol. And
it doesn't sound like the OP is designing the protocol, he's just
writing a client for an existing protocol, so the reasons for not using
it are irrelevant to him -- if he wants to access the server, he has to
talk its language.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Måns Rullgård 2004-10-20, 7:51 am |
| Barry Margolin <barmar@alum.mit.edu> writes:
> In article <yw1xis96ebew.fsf@ford.guide>,
> Måns Rullgård <mru@mru.ath.cx> wrote:
>
>
> If the specification of the application protocol says that the data is
> encoded as XML markup, then it's effectively part of the protocol. And
> it doesn't sound like the OP is designing the protocol, he's just
> writing a client for an existing protocol, so the reasons for not using
> it are irrelevant to him -- if he wants to access the server, he has to
> talk its language.
Well, in that case I can't but feel sorry for him. He'll have many
hours of nightmarish fights to look forward to.
--
Måns Rullgård
mru@mru.ath.cx
| |
| Chuck Dillon 2004-10-20, 5:50 pm |
| Måns Rullgård wrote:
> raj20013@yahoo.co.in (Raj) writes:
>
>
>
>
> XML is a markup language, not a protocol. Search google groups for
> xml and my name for reasons not to use it.
>
Could you please summarize. I found a long thread discussing a
proposal to use XML for config files that digressed into a discussion
of protocol but frankly haven't got the time nor inclination to
deconvolve it and try to discover your points.
If your point is that the M in XML doesn't stand for Magic I agree 100%.
If he had said XDR rather than XML would you have reacted differently?
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Måns Rullgård 2004-10-20, 5:50 pm |
| Chuck Dillon <spam@nimblegen.com> writes:
> Måns Rullgård wrote:
>
>
> Could you please summarize. I found a long thread discussing a
> proposal to use XML for config files that digressed into a discussion
> of protocol but frankly haven't got the time nor inclination to
> deconvolve it and try to discover your points.
>
> If your point is that the M in XML doesn't stand for Magic I agree 100%.
Something like that.
> If he had said XDR rather than XML would you have reacted differently?
Possibly.
--
Måns Rullgård
mru@mru.ath.cx
| |
| Mark Rafn 2004-10-20, 5:50 pm |
| >> raj20013@yahoo.co.in (Raj) writes:
[vbcol=seagreen]
> Måns Rullgård <mru@mru.ath.cx> wrote:
Barry Margolin <barmar@alum.mit.edu> wrote:[vbcol=seagreen]
>If the specification of the application protocol says that the data is
>encoded as XML markup, then it's effectively part of the protocol.
You're both right. XML is not a protocol. A number of protocols use XML for
encoding of both payload and protocol info. The original poster didn't ask a
very answerable question, which leads to a wider variety of responses
(including "I hate XML") than is perhaps desired.
Raj, knowing that a protocol uses xml for its data is not really enough to
help with implementing a client. What specifically are you stuck on, and what
level and type of answer are you looking for?
For instance, are you looking for help in reading or creating payloads based
on a well-known public schema? Are you looking for networking help in
actually sending/recieving messages (so XML is just a side-issue)? Are you
hoping to find a library that implements the complete protocol?
Providing a lot more detail (especially the actual protocol description and
name, and how far you've gotten in using it) in your question is likely to
provide far better answers.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
| |
| Barry Margolin 2004-10-20, 8:47 pm |
| In article <d0ii42-8qv.ln1@hydra.dagon.net>,
dagon@dagon.net (Mark Rafn) wrote:
>
>
> Barry Margolin <barmar@alum.mit.edu> wrote:
>
> You're both right. XML is not a protocol. A number of protocols use XML for
> encoding of both payload and protocol info. The original poster didn't ask a
> very answerable question, which leads to a wider variety of responses
> (including "I hate XML") than is perhaps desired.
I thought his question was very "answerable". I think he's basically
just looking for a library to assist in creating and parsing XML data,
much like the libraries that are used for XDR or ASN.1.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Lev Walkin 2004-10-23, 2:47 am |
| Barry Margolin wrote:
> In article <d0ii42-8qv.ln1@hydra.dagon.net>,
> dagon@dagon.net (Mark Rafn) wrote:
>=20
>=20
[vbcol=seagreen]
d[vbcol=seagreen]
=20[vbcol=seagreen]
ML for[vbcol=seagreen]
ask a[vbcol=seagreen]
>=20
>=20
> I thought his question was very "answerable". I think he's basically=20
> just looking for a library to assist in creating and parsing XML data, =
> much like the libraries that are used for XDR or ASN.1.
Modern ASN.1 compilers allow a programmer to encode and decode the data
using XML.
--=20
Lev Walkin
vlm@lionet.info
| |
| James Antill 2004-10-24, 2:47 am |
| On Wed, 20 Oct 2004 09:06:02 -0500, Chuck Dillon wrote:
> Måns Rullgård wrote:
>
> Could you please summarize. I found a long thread discussing a
> proposal to use XML for config files that digressed into a discussion
> of protocol but frankly haven't got the time nor inclination to
> deconvolve it and try to discover your points.
Well I can't speak for MÃ¥ns but given that I feel in a similar way...
.. A full XML parser is on the order of 15,000 lines of C. I would argue
that _no_ other protocol comes anywhere near that size, and that's just
for the parser (even with XML you still need to write all the code
to decide what to do). Good network protocols are small, and easy to
implement and audit.
.. Good protocols don't have multiple ways to do the same thing. XML has
at least 3 ways of representing the character '<'.
.. XML parsers are generally written from the POV of people working with
local documents ... not with receiving untrusted data directly from the
network.
.. Due to the above a significant number of people, when they say XML,
mean something with <tags> ... for instance AIUI Jabber isn't actually
XML, although it is advertised as such. And again even if you can use
one there are a whole bunch of constraints on top XML that you need to
write by hand.
> If he had said XDR rather than XML would you have reacted differently?
XDR doesn't have any of the above properties.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Roger Leigh 2004-10-24, 7:46 am |
| James Antill <james-netnews@and.org> writes:
> On Wed, 20 Oct 2004 09:06:02 -0500, Chuck Dillon wrote:
>
>
> Well I can't speak for MÃ¥ns but given that I feel in a similar way...
>
> . A full XML parser is on the order of 15,000 lines of C. I would argue
> that _no_ other protocol comes anywhere near that size, and that's just
> for the parser (even with XML you still need to write all the code
> to decide what to do). Good network protocols are small, and easy to
> implement and audit.
If you are simply using XML as a means of serialising/deserialising
objects to send along the wire, there's probably no requirement to
implement a /full/ XML parser. For example, Mike Sweet's Mini-XML
parser:
http://www.easysw.com/~mike/mxml/
It's pretty small and fast (23 KiB stripped), and is /far/ lighter
than monsters such as libxml2.
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
| |
| Måns Rullgård 2004-10-24, 7:46 am |
| Roger Leigh <${roger}@invalid.whinlatter.uklinux.net.invalid> writes:
> James Antill <james-netnews@and.org> writes:
>
>
> If you are simply using XML as a means of serialising/deserialising
> objects to send along the wire, there's probably no requirement to
> implement a /full/ XML parser. For example, Mike Sweet's Mini-XML
> parser:
>
> http://www.easysw.com/~mike/mxml/
>
> It's pretty small and fast (23 KiB stripped), and is /far/ lighter
> than monsters such as libxml2.
That's still quite a chunk of code. I'm looking at an MPEG transport
stream multiplexer I recently wrote. It takes as input a number of
MPEG PS/TS, AVI, or MPEG elementary streams, and produces a transport
stream, with optional real-time streaming. The size of this is 72 kB,
with no dependencies except libc.
--
Måns Rullgård
mru@inprovide.com
| |
| James Antill 2004-10-24, 5:49 pm |
| On Sun, 24 Oct 2004 11:44:20 +0100, Roger Leigh wrote:
> James Antill <james-netnews@and.org> writes:
>
>
> If you are simply using XML as a means of serialising/deserialising
> objects to send along the wire, there's probably no requirement to
> implement a /full/ XML parser. For example, Mike Sweet's Mini-XML
> parser:
But then what you are sending over the wire is _not_ XML, it's
something that uses <tags> ... which was my last point. And if you are
going to be incompatible then I'd argue that defining something that is
incompatible and _much_ simpler to implement/audit is relatively easy.
Also defining a protocol by sending objects over the wire isn't a good
idea. Imagine if SMTP had been defined by sending internal sendmail
objects over the wire.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Barry Margolin 2004-10-24, 8:46 pm |
| In article <pan.2004.10.24.21.35.18.303350@and.org>,
James Antill <james-netnews@and.org> wrote:
> Also defining a protocol by sending objects over the wire isn't a good
> idea.
That's what X.400 was like.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Chuck Dillon 2004-10-25, 5:52 pm |
| James Antill wrote:
> On Wed, 20 Oct 2004 09:06:02 -0500, Chuck Dillon wrote:
>
>
>
>
> Well I can't speak for MÃ¥ns but given that I feel in a similar way...
On application of XML I'm a "tweaner". I sit between the folks who
think XML is always the way to go, (Like the guy I worked with for a
while who claimed every time he applied XML he saw performance
improvements no matter what the metric.), and folks who shun it
completely. I'll play devil's advocate for a second...
>
> . A full XML parser is on the order of 15,000 lines of C. I would argue
> that _no_ other protocol comes anywhere near that size, and that's just
> for the parser (even with XML you still need to write all the code
> to decide what to do). Good network protocols are small, and easy to
> implement and audit.
If you compare all layers of the application, for a pure XML
implementation you have the XML parser and binding code. In the
non-XML case you have the custom protocol implementation and possibly
XDR, and some binding code. By binding code I mean the code that
translates between the binary form and the wire protocol form. I'm
guessing the amount of code is comparable if the application is complex
enough to require XDR or something comparable. If it is a given that
higher layers will be using XML then the XML parser will be available
and won't be an additional software component like XDR would be.
The real issue is the structure of the design, code and the data.
Without XML, if the tools are some simple and robust custom protocol
with XDR or complete abstraction for the payloads you have a clear
separation of the issues in the protocol layer from those in higher
layers. Modular design is a good thing. With XML, if the protocol
(DTD/Schema) spans the entire spectrum of the protocol and the data
representation for higher layers you have a monolith which is
inherently a bad thing. The XML people would argue that the Magic of
XML is that the data is structured so you have at least a well formed
and extensible monolith. A monolith is a monolith.
So, I would argue that if you use XML you should still keep the design
modular and not trick yourself into seeing modularity in a monolithic
DTD/Schema. It seems to me that the valid issues you and MÃ¥ns raise
apply directly to the lower layer(s) which must implement a clean
robust communications mechanism that should be independent of higher
layers. I have no disagreement with the arguments in the context of a
general purpose implementation that makes no assumptions about what
exists in higher layers.
However, if you have an XML house that is going to use XML in the
higher layers (hence a parser is already available) and knows the
issues of data representation because they are representing the same
data in XML in other layers then there really isn't any good argument
against them using XML over the wire, IMHO. Assuming they have
sufficient bandwidth to handle the overhead.
In fact, if they have expertise with XML they can leverage it and the
tools that support it to very quickly build a complex protocol that is
extensible. They can leverage off the shelf tools to ensure that they
have complete, correct and valid designs and content. There is a lot
of XML code out there to potentially be leveraged.
-- ced
>
> . Good protocols don't have multiple ways to do the same thing. XML has
> at least 3 ways of representing the character '<'.
>
> . XML parsers are generally written from the POV of people working with
> local documents ... not with receiving untrusted data directly from the
> network.
>
> . Due to the above a significant number of people, when they say XML,
> mean something with <tags> ... for instance AIUI Jabber isn't actually
> XML, although it is advertised as such. And again even if you can use
> one there are a whole bunch of constraints on top XML that you need to
> write by hand.
>
>
>
>
> XDR doesn't have any of the above properties.
>
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
|
|
|
|
|