ប្រើអ្នកផ្ដល់ឆានែលរបស់អតិថិជនដែលបានបង្កើត នៅពេលការតភ្ជាប់ 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 របស់ព័ត៌មានសម្ងាត់នោះ។ វានៅក្រៅអ្នកផ្ដល់ឆានែលដែលបានបង្ហាញនៅទីនេះ។

អត្ថបទពាក់ព័ន្ធ