កំណត់រចនាសម្ព័ន្ធឆានែល gRPC របស់ Pub/Sub Java សម្រាប់ HTTP CONNECT
ដំឡើង ProxyDetector តាមរយៈអ្នកផ្ដល់ឆានែល GAX ដោយរក្សាអាសយដ្ឋានគោលដៅ និងអត្តសញ្ញាណ TLS របស់ Pub/Sub។
ប្រើអ្នកផ្ដល់ឆានែលរបស់អតិថិជនដែលបានបង្កើត នៅពេលការតភ្ជាប់ 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 របស់ព័ត៌មានសម្ងាត់នោះ។ វានៅក្រៅអ្នកផ្ដល់ឆានែលដែលបានបង្ហាញនៅទីនេះ។