Thanks for the responses. That's basically what I thought... I was working on providing written proof that even the Response is an automatic behavior of http and the ack cannot be handled in anyway programatically. I was facing my IT Leadership that only knows about tcp communication an osi and the flow of the actual data between the two points.
Again, thanks! On 8/22/06, Nathan Strutz <[EMAIL PROTECTED]> wrote: > > Yep, HTTP and web applications are way, way above and removed from TCP ACK > types of things. The way I see it, you have 2 options. > > 1) have the request hang while you process the data > 2) require a post-back URL > > I personally would rather use a web service and stick with #1, but then I > don't know your project details. > > -nathan strutz > http://www.dopefly.com/ > > On 8/22/06, Dave Watts <[EMAIL PROTECTED]> wrote: > > > > > When another service (Requestor) sends a POST to one of our servers > > > (Responder), that page they POST to sends a Response by protocol, and > > > the Requestor sends back an Acknowledgement of that Response... Now, > > > how in the world can we make or server recognize that acknowledgment > > > and if it doesn't recieve an acknowledgement within a timeframe resend > > > the response? > > > > > > Here's the literal problem: > > > 1. Client POST's a request for an Order > > > 2. We Respond with an accepted/rejected status, and if accepted we > > > include an order #. > > > 3. We want to be sure they received the response based on the > > > acknowledgment that happens in http protocal flow. This breaks down to > > > the fundamentals of basic tcp communication and the entire OSI design. > > > > > > We don't want to have to do it with a workaround such as when the send > > > us a post, send another post back... we wan to take advantage of the > > > fundamentals of the entire communications design. > > > > You can't. That's not how HTTP works. You can only assume that the > > response > > was received by the program that made the request, or require an > > additional > > request from that program. This has nothing to do with basic TCP > > communication or the OSI model (beyond the fact that HTTP is an > > application > > protocol at layer 7 of the OSI model). > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > > > Fig Leaf Software provides the highest caliber vendor-authorized > > instruction at our training centers in Washington DC, Atlanta, > > Chicago, Baltimore, Northern Virginia, or on-site at your location. > > Visit http://training.figleaf.com/ for more information! > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:250658 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
