Yes that was exactly what I was asking. I guess I'm thinking maybe the right thing to do here is to write a "sample" transport that deals with the heavy lifting and can then be modified to handle the specifics of different endpoints as described below. That is, unless you believe that these settings and different approaches can all be captured in config information in some more general way?
Paul On Wed, May 28, 2008 at 3:35 PM, Bob Arthur <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 3:08 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> Bob >> >> Can I ask if there is any framing going on with your TCP transport? >> And what is flowing over it? It certainly would make sense for us to >> have a better non-blocking/streaming TCP transport and it would help >> if we could collect the requirements. > > Hi, > > I'm not 100% sure I follow the question - would I be right in thinking > that by "framing" you are asking how we recognise that a complete > message has been sent/received? Unfortunately, as a gateway providing > access to a number of 3rd-party services, this is variable across our > service base; in some cases messages are length-prefixed, in others we > perform a half-close after writing and read until the connection is > fully closed, while in others there are "end-of-data" marker > characters. > > All of which is, of course, not very helpful from the point of view of > adding support to a general-purpose framework! > > Cheers, > > Bob. > >> >> Paul >> >> On Wed, May 28, 2008 at 9:49 AM, Bob Arthur <[EMAIL PROTECTED]> wrote: >>> On Wed, May 28, 2008 at 3:19 AM, Asankha C. Perera <[EMAIL PROTECTED]> >>> wrote: >>>> Hi Bob / Andreas >>>>> >>>>> Actually I added two new transports: one for UDP and one to read from a >>>>> UNIX pipe (aka named pipe, aka FIFO). The UDP transport indeed uses a non >>>>> blocking approach, but it is a datagram transport in the sense that it >>>>> reads >>>>> the entire message into memory before starting to process it. The pipe >>>>> transport uses file I/O and is blocking (there is no non blocking file I/O >>>>> in Java). For various reasons it is actually also built as a datagram >>>>> transport, i.e. it doesn't support streaming. Currently the only TCP >>>>> transport implementation is the one from Axis2. Neither the UDP and nor >>>>> the >>>>> pipe transport implementation is useful as a starting point to build a TCP >>>>> transport. Indeed, a good TCP transport should be non blocking and support >>>>> streaming. Implementing this is a non trivial task as we learned from the >>>>> problems with the HTTP transport (SYNAPSE-321). >>>> >>>> Andreas, I am sorry I was not following up in detail the changes on the >>>> trunk due to the work on the release lately :).. >>>> >>>> Bob, if you are willing to support the development of a new non-blocking >>>> TCP >>>> transport, we could understand your requirements/expectations and look into >>>> the possibilities for implementation. >>> >>> Hi, >>> >>> Thanks for the quick responses on this; currently we are still in the >>> process of setting out the precise goals of the project, so it would >>> be a bit premature for us to commit to such support. However, this >>> has certainly given us some food for thought. >>> >>> Cheers, >>> >>> Bob. >>> >> >> >> >> -- >> Paul Fremantle >> Co-Founder and CTO, WSO2 >> Apache Synapse PMC Chair >> OASIS WS-RX TC Co-chair >> >> blog: http://pzf.fremantle.org >> [EMAIL PROTECTED] >> >> "Oxygenating the Web Service Platform", www.wso2.com >> > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
