Unikanie ukrywania informacji

Czasami programy celowo lub przypadkowo ukrywają informacje przed silnikiem do serializacji RPC. Oto kilka przykładów:

• Wysyłanie struktury danych jako niezróżnionego bloku bajtów
• Zwiększenie wydajności poprzez wykorzystanie efektu ubocznego z metody do przekazywania dodatkowych danych przez sieć.
• Próba zamaskowania uchwytu poprzez przekazanie go jako DWORD lub ULONG

Te techniki niemal na pewno spowodują problemy ze zgodnością, jeszcze zanim przeniesiesz aplikację do 64-bitowego systemu Windows.

Zamiast wysyłać kontekst serwera jako DWORD w standardowym zdalnym wywołaniu procedury, użyj uchwytu kontekstowego, aby zapewnić nieprzezroczyste dojście do kontekstu serwera przechowywanego w imieniu klienta. Konteksty są identyfikowane przez identyfikatory GUID zdefiniowane przez środowisko wykonywania RPC, gdy serwer tworzy uchwyt kontekstowy dla klienta. Wskaźnik nie jest używany przez sieć, a operacja jest całkowicie przezroczysta na granicach 32- lub 64-bitowych. Aby uzyskać więcej informacji na temat korzystania z uchwytów kontekstowych, zobacz Uchwyty kontekstowe.

Interfejsy DCOM nie mogą używać uchwytów kontekstowych, ponieważ COM zapewnia własne zarządzanie kontekstem. Zamiast tworzyć uchwyt kontekstu, można przekazać wskaźnik interfejsu do obiektu COM. Następnie można wywołać metody bezpośrednio za pomocą wskaźnika interfejsu lub umieścić wskaźnik wewnątrz innych wywołań. Aby klient mógł zwolnić obiekt serwera, wywołuje metodę Release poprzez wskaźnik interfejsu.

Ponownie może wystąpić czas, kiedy nie można zmienić oryginalnego projektu kodu, który przenosisz. Jeśli nie ma możliwości uniknięcia wysyłania wskaźnika przez przewód jako DWORD, należy zaimplementować jakąś formę mapowania po stronie serwera między DWORD wartości i wskaźniki. Jednym ze sposobów jest zmiana wskaźników w aplikacji po stronie klienta na typy precyzji wskaźnika, takie jak ULONG_PTR lub DWORD_PTR. Następnie użyj atrybutu MIDL [call_as] , aby umieścić wskaźniki na przewodzie jako wartości DWORD. Opakowanie po stronie klienta musi przekazywać tylko argumenty. Opakowanie po stronie serwera obsługuje mapowanie między dwoma typami. W podobny sposób można użyć atrybutu [transmit_as] lub atrybutu [represent_as] w celu przekonwertowania danych na format zgodny z poprzednimi wersjami dla reprezentacji przewodu.

Jeśli zgodność z wcześniejszymi wersjami interfejsu nie jest problemem lub jeśli uchwyt nie jest używany do wywołań zdalnych i masz pewność, że zdalne wywołania między procesami 32- i 64-bitowymi nigdy nie wystąpią, możesz ponownie zdefiniować argument jako ULONG64. W razie potrzeby można zmodyfikować aplikację 32-bitową, aby przekazać DWORD użytkownikowi. Alternatywnie można utworzyć oddzielne wycinki od oddzielnych plików IDL dla każdej platformy przy użyciu DWORD w 32-bitowych systemach Windows i ULONG64 w 64-bitowym systemie Windows.