On 05/28/14 19:24, Jiri Cincura wrote: > Hi Alex, > > I'm already for two days fighting with streaming restore via Services > API. Will it be possible to guide me through the one request-response > process. No matter what I try to do I'm not moving forward. > > If I read the "docs" correctly I need to send after op_service_start > the op_service_info with isc_info_svc_stdin, right? How the packet > should look like? Can you describe it in some high level words like > op_something here, isc_xxx_svc_xxx there etc?
I never used to analyze talking to service at packet level - only at API calls level. First of all we start (isc_service_start) restore service, passing "stdin" as backup file name. Next we always run isc_service_query in a loop as long as service keeps running. isc_service_query is rather cunning function - it has 3 clumplet-like parameters. First is data passed to the service, next is set of requests to it and last is buffer for answers to that requests. In the first call you never pass data to service - it may be passed only if previous call returned non-zero answer to request isc_info_svc_stdin (passed in second clumplet). If you expect that service may require stdin data that request should better be always present in requests clumplet. As soon as you get non-zero answer to isc_info_svc_stdin you may send not more than that number of bytes in data passed to service in next isc_service_query call. Sorry, have no idea how to describe it simpler. > Although I send this > packet fine and server responds with something that I can parse and > looks correct (it asks for 8K of data, not sure if it's expected) I > then just get "No request from user for stdin data". Comparing packets > from fbsvcmgr using Wireshark shows some differences even in this > op_service_info request. That's not good... Make sure how does data passed in packet match data and request parameters in isc_service_query. > Then what the response should look like, > again high level words is fine. Hmm... Very simple - when you find in answers buffer tag isc_info_svc_stdin (it comes in a 'company' with such tags as isc_info_svc_line, isc_info_svc_to_eof, isc_info_svc_svr_db_info, etc.) next 4 bytes [should be read from buffer using something like isc_vax_integer(buffer, 4)] is number of bytes that server is ready to receive from client in next isc_service_query call. > I was able to implement the backup more or less fine. But as you wrote > in the file, the restore is tricky - for me it feels like a touch bit > of hack. :) > :-) There are 2 independent and relatively slow processes - sending data over the wire and parsing them by gbak service. I wanted to have efficient buffering between network and gbak in order to let that processes run in parallel. At the same time I wanted to avoid unlimitedly growing buffer at server side (in case when user sends data faster than gbak cat "eat" them) and moreover errors like "overflow in server buffer, resend data later". At the same time it was necessary to keep async nature of isc_service_query, i.e. make it _not_ wait for a service to free buffer before giving an answer to the user - remember that we may set timeouts for this function and it also transfers stdout data from server to client. Therefore the only way I've found to satisfy all this requirements is explicitly sending to client info - how much stdin data may be accepted on the next call. A. PS. I've CCed an answer to devel list. ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
