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 >
