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 )