RE: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

[Usharani Kandula via Tech-talk <tech-talk at aps.anl.gov>]

Hi Team,

 

I wanted to follow up on the question I shared earlier. When you have a chance, I would appreciate any guidance or feedback you may have.

 

Thank you for your time.

 

Best regards,
Uharani

 

From: Usharani Kandula
Sent: Monday, August 24, 2026 9:52 AM
To: tech-talk at aps.anl.gov
Subject: RE: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

 

Hello Greg,

 

Thanks for the suggestion.

 

I double-checked the Java stack I’m using in my first trial (`org.epics:epics-pvaclient:4.3.2` with `epics-pvaccess:5.1.4-j8` and `epics-pvdata:6.1.4-j8`). I wasn’t able to find any obvious NTURI/URI-based direct-connect support in these versions (no `NTURI` references in the sources jars, and no `pva://` / URI parsing in the `PvaClient` APIs).

 

Could you please point me to the exact example/API you had in mind?

 

- Is there a specific class/method in `pvAccessJava`/`pvaClientJava` that accepts a URI like `pva://host:port/pvName`?

- Or is the NTURI example you mentioned intended for a different workflow (e.g., RPC services that accept an NTURI payload), rather than for client transport connection setup?

 

If you can share a link to the Normative Types NTURI example section (or a short code snippet), I can try it directly.

 

Best regards,  

Usha

 

 

 

From: Usharani Kandula
Sent: Tuesday, August 4, 2026 10:59 AM
To: tech-talk at aps.anl.gov
Subject: Java PVA client: connect directly to known IOC endpoint without any search (no UDP multicast/unicast, no TCP directed search)

 

Hello Team,

 

I’m looking for guidance on a Java PVA client use case where I already know the IOC endpoint for a PV (resolved via an internal lookup/database), and I want to connect directly to that IOC and read the PV without performing any PVA search.

 

Goal / Requirement

 

Given:

- PV name (example: `ABC:TEMP`)

- Known IOC endpoint (example: `127.0.0.1:5075`)

 

I want:

- No UDP multicast search

- No UDP unicast search

- No TCP directed search (i.e., avoid the `EPICS_PVA_NAME_SERVERS` search step)

- Instead: direct TCP connect + CreateChannel + read

 

In other words, since my internal lookup already tells me where the PV lives, I want to avoid asking the IOC again “do you have this PV?”

 

What I tried

 

1) Standard configuration to disable multicast/broadcast

I can disable multicast/broadcast discovery via:

 

```

EPICS_PVA_AUTO_ADDR_LIST=NO

EPICS_PVA_ADDR_LIST=

```

 

But the remaining supported approach is to use `EPICS_PVA_NAME_SERVERS=host:port`, which performs a directed TCP search. That still sends a search request to the IOC.

 

2) core-pva (Phoebus) low-level POC that skips search entirely

I built a proof-of-concept using `org.phoebus:core-pva:5.0.5` that successfully reads a PV from a known endpoint without any search.

 

High-level summary of the POC:

- Creates a `PVAClient`

- Creates a `PVAChannel`

- Unregisters it from search

- Creates a direct TCP handler to the known IOC endpoint

- Manually sets channel state to FOUND

- Registers the channel with the TCP handler (sends CreateChannelRequest)

- Connects and reads

 

This works (tested against a Python fake IOC), but it relies on package-private/internal APIs such as:

- `ClientTCPHandler`

- `ClientChannelState`

- `PVAChannel.setState()`

- `PVAChannel.registerWithServer()`

- `client.search.unregister()`

 

To access these, the POC code is placed in the same Java package as the library (`org.epics.pva.client`), which is not ideal for production.

 

 

Questions

1. Is there a supported/public Java API (in core-pva or elsewhere) to do a true direct connect to a known IOC endpoint without any search?

 

2. If not, would the community consider a change to core-pva to add a public API such as:

 

```java

PVAChannel connectDirect(String pvName, InetSocketAddress iocAddress)

```

that encapsulates the internal wiring currently required?

 

3. Are there protocol-level concerns with skipping search entirely (e.g., server GUID handling, channel lifecycle expectations) that would make this approach problematic?

 

Additional details

 

- Library: `org.phoebus:core-pva:5.0.5`

- Java: 21

- Current POC output shows successful connect/read and prints the returned `PVAStructure`.

 

Thanks in advance for any guidance.

 

Best regards,  

Usharani

Fermi National Accelerator Laboratory