Jump to content











Photo
- - - - -

Identifying the response associated with the request

imdisk devio proxy identify response code

  • Please log in to reply
1 reply to this topic

#1 imdiskuser

imdiskuser
  • Members
  • 4 posts
  •  
    United States

Posted 30 May 2013 - 08:36 PM

Hi Olof,

 

I'm trying to implement my own read/write handle using the proxy through devio. I'm basically trying to emulate a drive. Here, I'm forwarding all read/write requests to a queue and based on seek distance/offset etc from the current position, getting the best command to execute and returning the response.

 

Now, Imdisk does not limit the number of commands sent to the proxy correct? Does It just forward commands through TCP/SHM without any flow control? or wait for the response before executing the next command from the socket/SHM?

 

When working with drives backed with image file, does ImDisk notify the application that sends these read/write commands, which command was executed based on any tag? I noticed that the _IMDPROXY_READ_RESP only contains the error code and the length of the bytes read, have I missed anything?

 

Thanks for your patience.

 



#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 01 June 2013 - 12:35 PM

Hi,

 

The proxy mechanism always sends one request and waits for corresponding reply, before sending next request.

 

Requests from filesystems are sent to disk drivers as IRP, I/O Request Packet.

http://msdn.microsof...e/ff566991.aspx

After some basic checking, such as valid offset, byte range etc, ImDisk  put these messages in a queue and mark them with STATUS_PENDING. This means that if caller is doing overlapped/asynchronous I/O, they will get control back almost immediately. They can instead wait for outstanding packets to complete.

 

The queue is handled by a separate service thread, per device, that runs in System process. It synchronously fetches one queued packet at a time, handles it and marks it as completed, so that kernel I/O manager and caller knows that it is finished. When working with drives backed with image file or memory, this service thread directly reads and writes image file or memory block. In case of proxy, it formats a proxy message, sends it and waits for reply.

 

This means that it cannot send multiple requests to the proxy. To do so, it would need to be redesigned in a way such that it could have queues/worker threads or similar that handles for requests and replies. It would also need, like you mention, some kind of tag so that it would know later which IRP to complete when a reply arrives. When using shared memory, things would even more complicated. It would practically need a new shared memory buffer each time it handles a packet asynchronously, so that client and server do not overwrite eachother's data. It would also need a different synchronization mechanism between client and server, to tell which of the outstanding buffers to synchronize. Or something like this. However, the idea sounds interesting. If you or someone else goes for implementing something like this, I will do my best to support your efforts.

 

:cheers:







Also tagged with one or more of these keywords: imdisk, devio, proxy, identify response code

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users