Код ошибки HTTP 502 часто возвращался при вызове API Google EmbeddedAssistant по буферным протоколам через HTTP - PullRequest
0 голосов
/ 29 апреля 2019

Я пытаюсь вызвать Google Assistant API, используя Protocol Buffers (protobuf) вместо HTTP. Ссылаться на: https://googleapis.github.io/HowToRPC#grpc-fallback-experimental

Моя проблема в том, что я часто получаю HTTP код ошибки 502 при отправке запроса в серверную службу.

Чтобы проверить проблему, я написал скрипт на python для отправки (через HTTP POST) предварительно собранных protobuf двоичных файлов и проверки ответа. Результаты теста:

32KB audio data (about 1 second length of audio), 20 times post, 0 times 502 error received / 32KB 20/0, failure rate: 0%

2*32KB, 20/0, failure rate: 0%

3*32KB, 20/3, failure rate: 15%

4*32KB, 20/10, failure rate: 50%

6*32KB, 20/19, failure rate: 95%


HTTP status code is 200 for successful requests, while 502 for failed cases.

где мы можем видеть, чем больше длина звука, тем больше частота отказов.

Код python для post предварительно собранных protobuf двоичных файлов приведен ниже. в то время как содержимое файла f1 является просто protobuf двоичными файлами.

def postData():

url = "https://embeddedassistant.googleapis.com/$rpc/google.assistant.embedded.v1alpha2.EmbeddedAssistant/Assist"
header = {"Content-type".encode('utf-8'): "application/x-protobuf".encode('utf-8'),"Accept".encode('utf-8'):"text/plain".encode('utf-8'), "Connection".encode('utf-8'):"keep-alive".encode('utf-8'), "Authorization".encode('utf-8'):repToken.encode('utf-8')}

with open(fl) as f:
    r = requests.post(url, data=f, headers=header)
with open(fl + "_out", 'wb') as fd:
    print(r.status_code)
    fd.write(r.content)
    f.close()
    fd.close()

Я также пытался опубликовать двоичные файлы, содержащие недопустимые protobuf, например, mp3-файл, и в этом случае, независимо от размера файла, возвращается HTTP status code всегда 400 со следующим сообщением , которое только что ожидается .

Получен неверный полезный груз PROTO. Недопустимые данные запроса в теле потока, непредвиденный тип сообщения: 7a

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

...