Notes from OGSA-ByteIO Session at OGF19, Chapel Hill ==================================================== 6 people present Chairs noted that attendance has dropped off since Specification and Rendering have been published :-) It was suggested that we attend the Visualisation workshop to make sure we tie off the streaming case loose ends. Steve Pickles suggested that we look at CDDLM interop experiences notes that were written by Steve Loughran - there may be some useful things to note for the ByteIO interop process. The group examined Dave Berry's EMS data scenario GridFTP issue - GridFTP does not support partial data transfer, so this makes it difficult to use ByteIO directly in this case. The three protocols in the ByteIO specification document all assume that you encode the data in the response. However this is not a requirement of ByteIO, as you just need to encode what is required to get the data, which may utilise out of band communication. Mark talked around a scenario with a representative protocol "Mark's Efficient Transport Protocol". The Request specifies: read a bunch of data, IP Address Port. The service sets up the data connection and sends back a response "expect data now". The client is then just waiting for it. Michel mentioned that this is the same as his ||http based ByteIO implementation. With GridFTP, because of the lack of partial transfer you could implement something in which the first time you talk to the service, you get sent back information to gridftp the whole thing (file?), then store it locally and access chunks back on client - could implement this but it is a silly way to do it. Basically GridFTP is targetted to moving the whole chunk of data, whereas ByteIO targetted to being cleverer at getting just the bytes it needs. It was agreed to finish off the Use Case document: there are some more to collect from Mark and from Dave Berry (which may overlap) A question was asked again about when do you use ByteIO, and when do you use DMI/GridFTP. GridFTP is about transferring large amounts of data. ByteIO is about providing interfaces to tease out interesting information from resources. A GENESIS II/BES like example: ByteIO to stream the JSDL, GRidFTP to stage the data specified in the JSDL Comments on interoperability document from ETSI - we agreed to paste comment to public comments and answer - a telcon will be setup to discuss this. Andre was shown the UVa ByteIO demo. Then he asked: - is there a C/C++ client? - SAGA based plugin for ByteIO? - experiences wrt performance? Mark answered: - only implemented "simple" protocol - very inefficient, however previous experience suggests that aggressive caching will make it as good as anything else. So, should be good enough! Discussion of Experiences Document layout. We agreed the following structure: 1. Description of process (here's how we approached it) 2. Description of the actual interop experiment (here's how we set it up) - we will post endpoints publicly rather than having a F2F session MD: Java/JAX-WS MM: Java/Axis AK: Java/Axis 3. Results matrix (a table of check marks) 4. List of problems and issues 5. Comments sections - comments from each implementor - comments from authors 6. Conclusions - Which should be... "we believe that this shows that the specification is a good one"! -- Neil P Chue Hong | T: [+44] (0)131 650 5957 Project Manager, EPCC | F: [+44] (0)131 650 6555 Rm 2409, JCMB, Mayfield Rd. | E: N.ChueHong@epcc.ed.ac.uk Edinburgh, EH9 3JZ, UK | W: http://www.epcc.ed.ac.uk BT MeetMe: http://tinyurl.com/8mwhd - Code: 14712935# "A film is like a battleground. It's love, hate, action, violence, death - in a word, emotion." - Sam Fuller