. NET Framework - WCF - MTOM - Предотвратить многочастный / связанный - PullRequest
0 голосов
/ 10 февраля 2020

Все,

Я хочу использовать SOAP XML сервис, требующий MTOM для передачи файлов в виде вложений. Я контролирую только инициатора, а не серверную часть. При использовании службы. NET Framework автоматически преобразует сообщение в составное сообщение, в то время как сторона сервера не поддерживает это (и не может быть изменено в моем контроле). Я не могу найти порог, когда это поведение применяется, и я также не могу найти настройки, позволяющие мне предотвратить это. Размер вложенных документов ограничен, поэтому приложение простого формата / xop + xml не должно приводить к каким-либо проблемам или снижению производительности.

Некоторые фрагменты кода:

var endpointAddress = new EndpointAddress(GetUri());
var binding = new WSHttpBinding();
binding.MessageEncoding = WSMessageEncoding.Mtom;
var stackOverflowChannel = ChannelFactory<MyInterface>.CreateChannel(binding, endpointAddress);

stackOverflowChannel.ConsumeMe(request);

Все помощь очень ценится.

Ответы [ 2 ]

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

Спасибо за ваш ответ. Вчера вечером я обнаружил проблему ... По-видимому, при передаче сообщения с использованием MTOM оно всегда отправляется как составное сообщение. В DLL-библиотеках Microsoft существует жестко заданная граница, которая переключается на составную часть, начиная с 767 байт. Это в XmlMtomWriter.cs. Фрагмент кода:

    class XmlMtomWriter : XmlDictionaryWriter, IXmlMtomWriterInitializer
    {
        // Maximum number of bytes that are inlined as base64 data without being MTOM-optimized as xop:Include
        const int MaxInlinedBytes = 767;  // 768 will be the first MIMEd length

        int maxSizeInBytes;
        XmlDictionaryWriter writer;
        XmlDictionaryWriter infosetWriter;
        MimeWriter mimeWriter;

Это значение жестко закодировано и не может быть перезаписано, если вы не создадите собственную фабрику сериализации.

В моем случае проблема не была проблемой ... На стороне сервера была ошибка в их коде проверки, который предполагал, что это должен быть «ОДИН формат» в случае отправки вложения.

Переконфигурировав их конец, я смог обойти их ошибку и теперь все работает как ожидалось.

На стороне сервера был XDSToolkit (XDSTools).

Это не было проблемой безопасности, так как связь прошла успешно.

Спасибо за ваш ответ и время.

0 голосов
/ 11 февраля 2020

Как правило, если на сервере включен кодировщик MTOM, код клиента, который вы пишете выше, будет работать правильно. Следует также отметить, что Wshttpbinding использует безопасность уровня сообщений по умолчанию и требует, чтобы клиент предоставил windows учетные данные.

//logins account on the server side.
            client.ClientCredentials.Windows.ClientCredential.UserName = "administrator";
            client.ClientCredentials.Windows.ClientCredential.Password = "abcd1234!";

Наконец, я советую вам вызвать удаленную службу с помощью клиентский прокси.
https://docs.microsoft.com/en-us/dotnet/framework/wcf/accessing-services-using-a-wcf-client
С помощью инструмента adding the service reference на стороне клиента генерируется прокси-класс в Reference.cs и файлы конфигурации для обслуживания. Файл конфигурации находится в appconfig/webconfig, и содержащаяся в нем конфигурация привязки соответствует серверу. Мы можем использовать этот метод, чтобы определить конфигурацию сервера (поддерживает ли он Mtom).
На моей клиентской стороне, он работает как положено.

ServiceReference1.ServiceClient client = new ServiceClient();
            //logins account on the server side.
            client.ClientCredentials.Windows.ClientCredential.UserName = "administrator";
            client.ClientCredentials.Windows.ClientCredential.Password = "abcd1234!";
            Console.WriteLine(client.Test());

SOAP сообщение, захваченное Скрипач.
enter image description here
Я хотел бы узнать подробности ошибки вызова удаленной службы. Не стесняйтесь сообщить мне, если проблема все еще существует.

...