calculateImpliedVolatility causes Error 320

[philipbel]

Calling calculateImpliedVolatility (request 54) triggers error 320

13:26:40:358 (sync 13:26:39:723) -> [4;2;13;320;Error reading request. Please use 'Key=Value' format for Misc Options;]

Comparing to the Java client API (EClient.java), calculateImpliedVolatility:

1. Java uses version 2 instead of 3, and
2. it doesn't send the length of the options before sending the (possibly empty) list of options from impliedVolatilityOptions

[siongsheng]

Dug into this against a live gateway (serverVersion 157, ib_async 2.1.0) and pinned the exact trigger — it's the count field, not the version.

Client.calculateImpliedVolatility sends len(implVolOptions) before the options:

self.send(54, 3, reqId, contract, optionPrice, underPrice, len(implVolOptions), implVolOptions)

The server reads that 0 where it expects the misc-options string and rejects with error 320. The version stays 3 — the only change needed is dropping the count:

self.send(54, 3, reqId, contract, optionPrice, underPrice, implVolOptions)  # no len()

With that, the request goes through and returns a proper computation:

OptionComputation(tickAttrib=0, impliedVol=0.302, delta=None, optPrice=3.6, ..., undPrice=315.0)

Drop-in monkeypatch until it's released:

from ib_async.client import Client

def _calc_iv_fixed(self, reqId, contract, optionPrice, underPrice, implVolOptions):
    self.send(54, 3, reqId, contract, optionPrice, underPrice, implVolOptions)

Client.calculateImpliedVolatility = _calc_iv_fixed

Same root cause as #170 — there it just surfaces as a "timeout", because the rejected request never yields a tickOptionComputation so the wait never completes.

(Verified for the common empty-implVolOptions case. calculateOptionPrice looks like it has the identical len() line, so probably the same bug.)