Exemplos de bloqueio oportunista
Os exemplos a seguir mostram dados e movimentações de mensagens SMB à medida que bloqueios oportunistas são feitos e quebrados. Observe que os clientes podem armazenar dados de atributo de arquivo em cache, bem como dados de arquivo.
Observe também que esses exemplos se baseiam em situações em que os aplicativos cliente estão solicitando bloqueios oportunistas de servidores remotos. Esses processos são iniciados automaticamente pelo redirecionador de rede e pelo servidor remoto — não há envolvimento direto do aplicativo cliente ou dos aplicativos. Os processos descritos por esses exemplos podem ser generalizados em situações em que os aplicativos cliente locais estão solicitando diretamente bloqueios oportunistas do sistema de arquivos local, com a exceção de que nenhuma troca de dados pela rede está envolvida.
Bloqueio oportunista de nível 1
O diagrama a seguir mostra uma exibição de tráfego de rede de um bloqueio oportunista de nível 1 em um arquivo. As setas indicam a direção da movimentação de dados, se houver.
| Evento | Cliente X | Servidor | Cliente Y |
|---|---|---|---|
| 1 | Abre o arquivo, solicitações nível 1 bloqueio ==> | ||
| 2 | <== Concede bloqueio oportunista de nível 1 | ||
| 3 | Executa operações de leitura, gravação e outras ==> | ||
| 4 | <== Solicitações para abrir o arquivo | ||
| 5 | <== Quebra o bloqueio oportunista | ||
| 6 | Descarta dados de leitura antecipada | ||
| 7 | Grava dados ==> | ||
| 8 | Envia a mensagem "close" ou "done" ==> | ||
| 9 | Oks open operation ==> | ||
| 10 | Executa operações de leitura, gravação e outras ==> | <== Executa operações de leitura, gravação e outras |
No caso 1, o cliente X abre um arquivo e, como parte da operação aberta, solicita um bloqueio oportunista de nível 1 no arquivo. No caso 2, o servidor concede o bloqueio de nível 1 porque nenhum outro cliente tem o arquivo aberto. O cliente continua a acessar o arquivo da maneira usual no evento 3.
No caso 4, o cliente Y tenta abrir o arquivo e solicita um bloqueio oportunista. O servidor vê que o cliente X tem o arquivo aberto. O servidor ignora a solicitação de Y enquanto o cliente X libera quaisquer dados de gravação e abandona seu cache de leitura para o arquivo.
O servidor força X a limpo enviando para X uma mensagem SMB quebrando o bloqueio oportunista, evento 5. O Cliente X "silenciosamente" descarta todos os dados de leitura antecipada; em outras palavras, esse processo não gera tráfego de rede. No caso 7, o cliente X grava todos os dados de gravação armazenados em cache no servidor. Quando o cliente X termina de gravar dados armazenados em cache no servidor, o cliente X envia uma mensagem "fechar" ou "concluída" para o servidor, evento 8.
Depois que o servidor tiver sido notificado de que o cliente X terminou de liberar seu cache de gravação para o servidor ou fechou o arquivo, o servidor poderá abrir o arquivo para o cliente Y, no evento 9. Como o servidor agora tem dois clientes com o mesmo arquivo aberto, ele concede um bloqueio oportunista a nenhum dos dois. Ambos os clientes continuam a ler do arquivo e um ou nenhum grava no arquivo.
Bloqueio oportunista em lote
O diagrama a seguir mostra uma exibição de tráfego de rede de um bloqueio oportunista em lote. As setas indicam a direção da movimentação de dados, se houver.
| Evento | Cliente X | Servidor | Cliente Y |
|---|---|---|---|
| 1 | Abre o arquivo, solicita o bloqueio em lote ==> | ||
| 2 | <== Concede bloqueio oportunista em lote | ||
| 3 | Lê o arquivo ==> | ||
| 4 | <== Envia dados | ||
| 5 | Fecha o arquivo | ||
| 6 | Abre o arquivo | ||
| 7 | Pesquisa dados | ||
| 8 | Lê dados ==> | ||
| 9 | <== Envia dados | ||
| 10 | Fecha o arquivo | ||
| 11 | <== Abre o arquivo | ||
| 12 | <== Quebra o bloqueio oportunista | ||
| 13 | Fecha o arquivo ==> | ||
| 14 | Oks open operation ==> | ||
| 15 | <== Executa operações de leitura, gravação e outras |
No bloqueio oportunista do lote, o cliente X abre um arquivo, evento 1, e o servidor concede ao cliente X um bloqueio em lote no evento 2. O Cliente X tenta ler dados, evento 3, ao qual o servidor responde com dados, evento 4.
O evento 5 mostra o bloqueio oportunista em lote no trabalho. O aplicativo no Cliente X fecha o arquivo. No entanto, o redirecionador de rede filtra a operação de fechamento e não transmite uma mensagem de fechamento, executando assim um fechamento "silencioso". O redirecionador de rede pode fazer isso porque o cliente X tem propriedade exclusiva do arquivo. Posteriormente, no evento 6, o aplicativo reabrirá o arquivo. Novamente, nenhum fluxo de dados pela rede. No que diz respeito ao servidor, esse cliente teve o arquivo aberto desde o evento 2.
Os eventos 7, 8 e 9 mostram o curso usual do tráfego de rede. No caso 10, outro fechamento silencioso ocorre.
No evento 11, o cliente Y tenta abrir o arquivo. A exibição do arquivo do servidor é que o cliente X o tem aberto, mesmo que o aplicativo no cliente X o tenha fechado. Portanto, o servidor envia uma mensagem quebrando o bloqueio oportunista para o cliente X. O Cliente X agora envia a mensagem de fechamento pela rede, evento 13. O evento 14 segue quando o servidor abre o arquivo para o cliente Y. O aplicativo no cliente X fechou o arquivo, portanto, ele não faz mais transferências de ou para o servidor para esse arquivo. O Cliente Y inicia transferências de dados como de costume no evento 15.
Entre a hora em que o cliente X recebe o bloqueio no arquivo no evento 2 e o fechamento final no evento 13, todos os dados de arquivo armazenados em cache são válidos, apesar das operações de abertura e fechamento do aplicativo intervindo. No entanto, depois que o bloqueio oportunista for interrompido, os dados armazenados em cache não poderão ser considerados válidos.
Filtrar Bloqueio Oportunista
O diagrama a seguir mostra uma exibição de tráfego de rede de um bloqueio oportunista de filtro. As setas indicam a direção da movimentação de dados, se houver.
| Evento | Cliente X | Servidor | Cliente Y |
|---|---|---|---|
| 1 | Abre o arquivo sem direitos de acesso ==> | ||
| 2 | <== Abre o arquivo | ||
| 3 | Solicitações filtram lock==> | ||
| 4 | <== Concede bloqueio | ||
| 5 | Abre o arquivo para leitura ==> | ||
| 6 | <== Reabra o arquivo | ||
| 7 | Lê dados usando o identificador de leitura ==> | ||
| 8 | <== Envia dados | ||
| 9 | <== Envia dados | ||
| 10 | <== Envia dados | ||
| 11 | <== Abre o arquivo | ||
| 12 | Abre o arquivo ==> | ||
| 13 | <== Bloqueio de filtro de solicitações | ||
| 14 | Nega o filtro lock==> | ||
| 15 | <== Lê dados | ||
| 16 | Envia dados ==> | ||
| 17 | Lê dados (armazenados em cache) | ||
| 18 | Fecha o arquivo ==> | ||
| 19 | <== Fecha o arquivo |
No bloqueio oportunista de filtro, o cliente X abre um arquivo, o evento 1 e o servidor responde no evento 2. Em seguida, o cliente solicita um bloqueio oportunista de filtro no evento 3, seguido pelo servidor que concede o bloqueio oportunista no evento 4. Em seguida, o Cliente X abre o arquivo novamente para leitura no evento 5, ao qual o servidor responde no evento 6. Em seguida, o cliente tenta ler dados, aos quais o servidor responde com dados, evento 8.
O evento 9 mostra o filtro bloqueio oportunista no trabalho. O servidor lê antes do cliente e envia os dados pela rede, mesmo que o cliente não tenha solicitado. O cliente armazena os dados em cache. No caso 10, o servidor também prevê uma solicitação futura de dados e envia outra parte do arquivo para o cliente armazenar em cache.
No caso 11 e 12, outro cliente, Y, abre o arquivo. O Cliente Y também solicita um bloqueio oportunista de filtro. No caso 14, o servidor nega. No caso 15, o cliente Y solicita dados, que o servidor envia no evento 16. Nada disso afeta o cliente X. A qualquer momento, outro cliente pode abrir esse arquivo para acesso de leitura. Nenhum outro cliente afeta o bloqueio de filtro do cliente X.
O evento 17 mostra os dados de leitura do cliente X. No entanto, como o servidor já enviou os dados e o cliente os armazenou em cache, nenhum tráfego cruza a rede.
Neste exemplo, o cliente X nunca tenta ler todos os dados no arquivo, portanto, a leitura antecipada indicada pelos eventos 9 e 10 é "desperdiçada"; ou seja, os dados nunca são realmente usados. Essa é uma perda aceitável porque a leitura antecipada acelerou o aplicativo.
No caso 18, o cliente X fecha o arquivo. O redirecionador de rede do cliente abandona os dados armazenados em cache. O servidor fecha o arquivo.