जब Pub/Sub Java gRPC जडानलाई HTTP CONNECT प्रोक्सी आवश्यक पर्छ, उत्पन्न गरिएको क्लाइन्टको च्यानल प्रदायक प्रयोग गर्नुहोस्। सामान्य URLConnection सेटिङले यो च्यानल कन्फिगरेसन स्थापित गर्दैन।

topic-admin क्लाइन्टका लागि:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient र TopicAdminSettings Pub/Sub v1 कक्ष हुन्; HttpConnectProxiedSocketAddress io.grpc बाट आउँछ र InetSocketAddress java.net बाट। उदाहरणले यो च्यानलले प्रयोग गर्ने सामान्य इन्टरनेट-ठेगाना लक्ष्य मान्छ।

डिटेक्टरले मूल लक्ष्यसँगै प्रोक्सी जडान ठेगाना फर्काउँछ। gRPC निर्माताले प्रोक्सी ठेगाना समाधान भएको हुनु आवश्यक ठान्छ। सेवा अन्त्य बिन्दुलाई Pub/Sub नै राख्नुहोस्: यसलाई प्रोक्सी होस्टनामले प्रतिस्थापन गर्दा सेवा लक्ष्य र अभिप्रेत TLS पहिचान गुम्नेछ।

प्रमाणीकरण नभएको प्रोक्सीका लागि प्रयोगकर्तानाम/पासवर्ड कलहरू हटाउनुहोस्; सार्वजनिक HTTP उम्मेदवारहरू HTTP प्रोक्सी सूचीमा भेटिन्छन्। ती कलहरू HTTP CONNECT प्रमाण-पत्र इन्टरफेस हुन्, SOCKS वा सामान्य NTLM कार्यान्वयन होइनन्।

यदि असफलता gRPC कार्यअघि हुन्छ र स्वतन्त्र रूपमा सिर्जना गरिएको प्रमाण-पत्रले टोकन प्राप्त गर्छ भने, त्यो प्रमाण-पत्रको HTTP मार्ग जाँच्नुहोस्। त्यो यहाँ देखाइएको च्यानल प्रदायकभन्दा बाहिर छ।

सम्बन्धित लेखहरू