LINUX.ORG.RU
ФорумAdmin

http relay server?

 , ,


1

4

Ищется http relay server. Или какая-то прокся, которую можно настроить как релейку.

Юзкейс:

На бекенде есть потоковая приблуда (да, поток по http), которая, ввиду своей архитектуры и неповоротливости, не тянет требуемое кол-во клиентов. Нужно забирать поток (в свой буфер), множить и раздавать его конечным клиентам.

Я понимаю, что будут задержки, но 3-7 секунд не критично.

Подскажите какое ПО так умеет? Можете перечислить несколько — в любом случае буду ковырять и тестировать.

Ответ на: комментарий от Atlant

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

deep-purple ★★★★★ ()
Ответ на: комментарий от Serge10

Подробнее можно? Кинься ссылкой на страничку документации где написано как зарелеиться?

deep-purple ★★★★★ ()
Ответ на: комментарий от Atlant

Вот тебе технически аналогичный пример:

Видео- аудио- поток по какому-либо протоколу релеится именно так. Мастер-релей провайдит потоки, а слейв-релеи «смотрят/слушают» его как обычные клиенты, но в свой буфер, чтобы раздавать копию потока уже самим клиентам (плеерам). Таким образом снижается нагрузка на мастер-релей.

Т.е. какой-нить обратный прокси мне не подойдёт, т.к. он отдаёт соединение в бекенд. И апстрим не подойдёт — поставщик данных у меня один и может быть только один.

deep-purple ★★★★★ ()

присоединяюсь к вопросу

r0ck3r ★★★★★ ()
Ответ на: комментарий от deep-purple

Squid конечно можно настроить, но думаю проще будет для данного случая - обычный nginx настроить https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachin...

Atlant ★★★★★ ()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от deep-purple

обратный прокси мне не подойдёт

у серверной части не устанавливаются заголовки по допустимому времени хранения?

Atlant ★★★★★ ()
Ответ на: комментарий от Atlant

Зафиксировать что? Время хранения? Для «постоянно изменяющегося» потока? Зачем?

Не мудри. Есть поток, который надо не кешировать, а пополнять его данными свой кольцевой буфер (one writer, many listeners), с которого раздавать данные клиентам. Ну да — сначала обменяться заголовками рукопожатия с клиентом, а потом слать поток из буфера. Вот прям с того места с какого получится. Главное — клиент начнет получать данные.

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 2)
Ответ на: комментарий от deep-purple

т.е. нужно промежуточное звено, которое знает структуру приходящего потока данных и умеющего в любой момент времени подключить нового клиента и посылать данные не с начала, а с текущего «условного байта»?
Тогда не знаю, это вероятно только собственная разработка нужна.

Atlant ★★★★★ ()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от Atlant

Тще, да. Ну давай подождём может кто знает приблуду такую. Вон, для звука и видео решения существуют. Чому для хттп не может быть?

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Потому что для звука и видео всё заточено под звук и видео: прокси-серверы (мультиплексоры) звука или видео не просто данные ретранслируют, а анализируют поток, вставляют заголовки туда, где нужно (при подключении клиента, например), могут демуксить и обратно муксить его.

В общем случае — решения вашей проблемы не существует.

ValdikSS ★★★★★ ()

Запили сам. Вот, например

import aiohttp
from aiohttp import web
import asyncio

CHUNK_SIZE = 1024
URL = 'http://ice3.somafm.com/deepspaceone-128-mp3'

clients = set()

async def reader(url):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as resp:
            while True:
                data = await resp.content.read(CHUNK_SIZE)
                if not data:
                    break
                for client in clients:
                    await client.write(data)

async def handle(request):
    response = web.StreamResponse()
    response.content_type = 'audio/mpeg'
    await response.prepare(request)
    clients.add(response)
    try:
        while True:
            await asyncio.sleep(1)
    finally:
        clients.remove(response)

async def on_startup(app):
    asyncio.create_task(reader(URL))

app = web.Application()
app.add_routes([web.get('/', handle)])
app.on_startup.append(on_startup)

pawnhearts ★★★★★ ()
Ответ на: комментарий от ValdikSS

не просто данные ретранслируют, а анализируют поток, вставляют заголовки туда, где нужно

Так а я про что?

свой кольцевой буфер (one writer, many listeners), с которого раздавать данные клиентам. Ну да — сначала обменяться заголовками

К тому же, мне нужны только заголовки при коннекте, а затем плевать. Более того, для звука оно так поверх хттп и работает, но там расширенный протокол (доп-заголовки), а мне нужен чистый хттп.

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Сейчас глянул на код, в reader при if not data надо не break, а падать. Или перезапускаться. Иначе при обрыве соединения с источником данных оно просто перестанет работать. Вообще это можно легко переписать на го или даже на си, но посколько оно нихрена не делает кроме пересылки данных, это должно достаточно хорошо работать и так. т.к. код асинхронный соединений может висеть очень много.

pawnhearts ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.