[Zope] XML-RPC,Zope and Vb.NET Client Application
Richard Barrett
R.Barrett@ftel.co.uk
Thu, 30 Jan 2003 15:19:34 +0000
At 12:46 30/01/2003, Zope@Stylus wrote:
>HI
>
>Thanks for this very detailed explanation.
>I would like to explain what I have understood with respect to XML-RPC
>
>I have a client side application in VB.NET sending XML-RPC request on a TCP
>connection
>The Linux Machine on which Zope-2.5.1 is installed and running on port 8080
>also has an XML-RPC server running on port 9092 on the machine (xmlrpclib
>from www.pythonware.com )
>But I have understood that Zope understands XML-RPC requests without a
>Server running on the machine.
>That means even if I dont have an XML-RPC server running on the Linux
>machine it is ok as long as the request is to the Zope Server.
>SInce I am sending requests to Python Scripts written in Zope and the Zope
>server understands XML-RPC requests
>I dont need a separate XML-RPC Server for this.
>But if I was trying to access any other python files outside Zope then I
>would need to have an XML_RPC server running tp listen to the requests.
>Also since my requests to Zope are coming over the TCP it is keeping a track
>of the server and Client details.
>So the Server knows from which IP the request has come.
>The Problem arises because the Proxy Server I.P. from my firm is the I.P
>that the server will get with a request.
>But within the LAN there are a number of machines sending requests to the
>Remote Zope Server simultaneously.
>When the Zope Server sends response it will send the reponses back to the
>coprrect I.P. which is the Proxy I.P.
>But then requests from each machine in the LAN will need to be tracked by
>the Proxy with respect to say some unique Identifying Variable that I send
>with each request and response.
All TCP/IP connections, are uniquely identified by the source and
destination IP numbers and the source and destination port numbers. There
can only be one current TCP/IP connection between any two machines with a
given combination of source IP/port and destination IP/port numbers.
As a resonable simplification, when a proxy server is involved in the HTTP
request (this being the transport for the XMP-RPC) then that proxy server
has two uniquely identified connections, one to the client and the other to
the server, for every request it is handling on behalf of a client.
Remember that HTTP is itself based on TCP/IP and as such is a connection
oriented protocol offering error-free delivery. The proxy just has to keep
track of the association between its connections to client and server for
each request so that the response returned over a server connection is then
passed back over the correct, associated, client connection.
I guess I am saying that a client which initiates an XML-RPC exchange with
a server using HTTP as transport via an HTTP proxy that works properly does
not have to include anything in the application (XML) payload of the
request in order to get the response returned to it reliably by the proxy;
all that stuff is dealt with by the protocol and proxy implementation.
HTTP/1.0 KeepAlive and HTTP/1.1 persistent connections mean that multiple
request/response pairs can move between client and server over the same
connections but this doesn't change the assertion about not needing
anything in the application payload to have the data flow reliably.
What you may well need to do in order to use XML-RPC to a Zope, or any
other sort of server is have your client code supply the user
authentication credentials, if any, that the server is expecting to see
accompany each request. Thus if the target Zope server is using Basic
Authentication your client would need to add an HTTP Authorization header
to the HTTP request; for example see http://www.zope.org/Members/Amos/XML-RPC
If your server uses other forms of authentication such as cookies or SSL
with server and client certificates, your client's implementation may be
more complex. But the authentication information is not needed to ensure
reliable data transfer between the requesting client and responding server.
Keep in mind that HTTP is about a request soliciting a response and the
protocol has no 'memory' of the what has gone before once the response has
been delivered. For HTTP the unit of transaction is a request and its
response and that an end of it.
If your application requires a sequence of related HTTP transactions, say
like a shopping trolley application, then the issue is how and where
multi-phase transaction state is maintained. What do we layer on top of
HTTP itself. A commonly used method of handling this is for the server to
maintain 'session' information, give the client a session identifier when
the transaction starts, and have the client return that session id in the
payload; this is to remind the server of what the client is talking about
on each subsequent request forming part of the whole multi-phase
transaction. Typically the HTTP cookie mechanism is used to pass the
session id to the client and for it to subsequently return it to the server.
I believe that there are Zope packages providing session support.
I guess you could view session cookies or some such as the 'Unique
identifier' you talk of; an identifier that links together the different
phases of a multi-phase transaction.
btw: the idea of the server initiating connections back to the client as
suggested in the earlier contribution below is a non-starter where clients
may be hidden behind proxy servers on a firewall. Often such clients are
literally un-addressable from outside their home domain because they may
have private IP numbers; as such they cannot be reached from outside the
domain in which they sit.
>I don't know how clearly I have been able to explain what I am trying to do
>here.
>I have been able to send and receive request and responses based on a unique
>Id generated when the User Logs in to the Application.
>This Id is generated in Zope and sent back along with the response after
>validating the USer for correct Login.
>Now everytime a Request or response is sent till the time that the User
>doesnot Log out the Same process of sending and Receiving requests and
>responses along with the Unoique Id is how I am doing it.
>Could anyone think of a better Idea as to how to solve this problem in a
>more defined Manner?
>All help received is GREATLY appreciated.
>Thanks and Best regards
>John Kunchandy
>============================================================================
>=======
>jwsacksteder@ramprecision.com <jwsacksteder@ramprecision.com>
> Think about it like this:
> >
> > XML-RPC works exactly like web page requests. Normally a browser contacts
>a
> > web server with a tcp connection and sends a http GET command. The server
> > then responds with a HTML document ON THE SAME TCP CONNECTION.
> >
> > With XML-RPC you are sending a RPC request as a formatted XML document to
>a
> > server over the HTTP transport protocol and the server responds by sending
> > the results of that RPC request back as formatted XML.
> >
> > In this situation, you are bound by the limitations of that single tcp
> > connection. Most notably, idle timeouts. If you have a request that takes
>15
> > minutes to process, the tcp connection will have died long before the
> > request comes back. XML-RPC does not specifically address persistant
> > connections like this. SOAP is an extension of XML-RPC that adds support
>for
> > this, though some would say that goes against the principles of XML-RPC.
> >
> > Most likely, what you want is to have XML-RPC servers/listeners on the
> > clients as well. What you have then is a peer-to-peer messaging network. A
> > client can send a XML-RPC request to a server, along with its address,
>name
> > and cryptographic key and when the response is ready, the server will
> > initate a NEW XML-RPC message and send it back to the originator. If you
>use
> > a public-key crypto system, you are protected from sending data to the
>wrong
> > client if the ip address changes.
> >
> > If you had a application where a server needed to notify clients when
> > certain things happened, you would have to make the clients register
> > themselves somehow with the server when they first started. Otherwise the
> > server would never know where the clients are.
> >
> > It might be worth your time to run through the XML-RPC transaction by hand
> > to see what is happening. Just telnet to whatever port your server is
> > listening(ex. telnet 192.168.0.1 80) on and type a simple XML-PRC request
> > and see what comes back in the terminal window.
>============================================================================
>========
> > I am working on an VB.NET client side application that sends requests in
> > XML-RPC to a Zope server running on Linux(Mandrake 8.0)
> > The request calls a python script and it returns a String .
> > But when there are multiple requests (i.e; from different machines on the
> > network) .the XmlRPc Server throws an XML RPC Fault Error.
>The 2.6 "xmlrpc.py" file provides support for a traceback.
>It will tell you about the location and cause of the exception.
>
>I think, I posted a patch with similar functionality for Zope 2.5.1.
>Search the archives...
>
> > Does XML-RPC Server maintain a record of the IP address of the client
> > machine that sent the request so that it can respond back to the same
> > machine?
>No, it does not.
>
>TCP/IP connections (and therefore HTTP and
>XML-RPC connections) are bi-directional.
>You can read and write to them. TCP/IP transparently handles
>the transport. (Of course, TCP/IP knows the IP address of both
>ends of the connection).
>
>
>
>Dieter
> >
>
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.443 / Virus Database: 248 - Release Date: 1/10/2003
>
>
>_______________________________________________
>Zope maillist - Zope@zope.org
>http://lists.zope.org/mailman/listinfo/zope
>** No cross posts or HTML encoding! **
>(Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )