search

Juniper / go-netconf

NETCONF implementation in Go.
Other
253 stars 110 forks source link

NewSession:SendHello prior to ReceiveHello is better #88

Open lyonsdpy opened 5 years ago

lyonsdpy commented 5 years ago

I had tested this tool on several type of devices，like juniper、huawei、cisco、h3c, bug there's a problem with h3c devices there have a half of change that the read() hangs forever because go-netconf NewSession() handle send hello after receive, this may cause the first data request was send follow closely with hello. then device receive hello and handle it and drop the data request.(because the hello package does not processing completed ) So I interchange the posstion of the hello send and receive. It work well

kpostrup commented 4 years ago

I am experiencing the same issue, using a Huawei device. The first Exec() request would take up to 5 seconds to complete while subsequent requests would execute immediately. In a small demo application, where I would execute the following get-config request, it would take almost 7 seconds to complete,

<get-config><source><running/></source><filter>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>%s</name>
    </interface>
  </interfaces>
</filter></get-config>

Running the same in Python using the ncclient library, would take below 2 seconds.

I have only shortly tested this, by doing as @lyonsdpy suggested, switching the order of t.SendHello() and t.ReceiveHello() and it solves the delay I'm experiencing. All the commands are now executed quickly without delay.

nemith commented 2 years ago

This is against the standard: https://datatracker.ietf.org/doc/html/rfc6241#section-8.1

Each peer sends its element simultaneously as soon as the connection is open. A peer MUST NOT wait to receive the capability set from the other side before sending its own set.

@kpostrup Your change looks good. Can you cut a PR? Your change is correct.