. NET удаленная цель, отказывающаяся от одного вызова - возвращает исключение socketexception - PullRequest
1 голос
/ 20 февраля 2020

У меня есть старая школа. NET удаленное приложение, которое мне нужно было немного расширить. Как часть этого я принес это. NET 4.0. (раньше был. NET 2.0) Хостинг интерфейса выглядит следующим образом

    public interface IRemoteSupportVM
    {
        string runAnOperation(Customer cust, List<CustomRoute> routes);

        string runAnotherOperation(string customer, string routes);

        string runAThirdOperation(List<string> pathsToBeCleaned);

        string writeFile(string path, string filename, int type, byte[] data);

        string readFile(string path, string filename, out byte[] data);

        string deleteFile(string path, string filename);

        long ping();
    }

ping, readFile, writeFile и deleteFile работают просто отлично. Когда я вызываю runAnOperation / runAnotherOperation / runAThirdOperation, я сразу получаю SocketExcepting, сообщая мне

Попытка подключения не удалась, потому что подключенная сторона не ответила должным образом через определенный период времени, или не удалось установить соединение, так как подключенный хост не смог ответить

Теперь я теперь вздор, потому что все остальные вызовы работают нормально, и цель получает вызов и выполняет его. Но так как клиент думает, что вызов не удался, все, что приходит после вызова connect, тоже терпит неудачу.

решение имеет множество других интерфейсов удаленного взаимодействия, и, насколько я могу судить, все они работают, кроме этих двух вызовов методов. Есть идеи, что могло бы сбить с толку вызывающего абонента. NET?

@ edit: Я заметил еще одну вещь: операции run * требуют времени для завершения. Другие операции возвращаются немедленно. Поскольку у меня есть код обеих сторон интерфейса удаленного взаимодействия, я установил точку останова для реализации ping (), и теперь я также получаю исключение SocketException, когда клиент вызывает ping. Так что, похоже, тайм-аут, о котором я не знаю.

1 Ответ

1 голос
/ 20 февраля 2020

Хорошо, так что после мучительного периода проб и ошибок я наконец нашел виновника. Это тайм-аут канала, когда он инициализируется. Вот как это было в коде удаленной стороны:

            IDictionary props = new Hashtable
            {
                ["port"] = config.Port,
                ["timeout"] = config.RemotingTimeout,
            };
            var channel = new TcpChannel(props, clientProv, serverProv);

Теперь кажется, что свойство тайм-аута не влияло на. NET 2.0 - есть довольно много результатов Google для этого эффекта. Тем не менее, в. NET 4.0, кажется, вдруг Каждый удаленный вызов упакован в IAsyn c* Begin / EnvInvoke, чтобы обеспечить результат по истечении заданного времени ожидания (даже если этот результат заключается в том, что сервер не предоставил результат во времени). Так что либо никто не заметил, что тайм-аут не имеет никакого значения, либо обертка выполнения была установлена ​​именно по этой причине (программное обеспечение было запущено 15 лет go .. так что кто знает).

Как config.RemotingTimeout было 70, на вызов ушло 70 миллисекунд, иначе я бы получил исключение SocketException. Когда я преобразовал 70 секунд (что я ожидал) в миллисекунды (так что timeout = 70000), все вдруг начало работать так, как я ожидал.

...