Сережа Ахен

https://docs.python.org/3/library/json.html

from json import loads, dumps

s = '{"foo": "bar"}'
d = loads(s)
print(d)
del d['foo']
print(d)
print( dumps(d) )

Если кратко, то существуют 4 вида NAT-а, которые нужно как-то преодолевать, 3 из них лекго преодолеваются при помощи STUN-серверов (они используются только в момент соединения пиров друг с другом - то-есть весь трафик через них не идет, есть куча бесплатных stun-серверов), четвертый - самый проблемный, под него подпадают примерно 15% всех peer-to-peer соеднинений в Интернете - это так называемый двойной NAT (когда оба пира скрыты за NAT-ом). Для преодоления этого четвертого вида NAT-а нужен TURN-сервер. Его особенность в том, что он работает как прокси - то-есть пропускает весь трафик через себя - отсюда вы должны понять, что бесплатных TURN-серверов вы не найдете. Те аккаунты, что вы привели сверху скорее всего уже давно отключены.

Отличный список STUN-серверов можно взять здесь - https://github.com/DamonOehlman/freeice он там постоянно проверяется и обновляется.

Проблемя с двойным NAT-ом решается одним из трех способов:
1. где-то находите временно халявный аккаунт на TURN-сервер (но аккаунт внезапно могут отключить)
2. покупаете платный аккаунт на уже существующем сервере и платите за трафик, например здесь - https://my.xirsys.com/signup/plans/standard/monthly
3. Разворачиваете свой turn-сервер. Мы, например, так и сделали. Взяли убунту за $5 в месяц на digitalocean и поставили там за пол дня опенсурсный, бесплатный turn-server - turnserver.open-sys.org/downloads

Радуюсь новому проекту

Оцениваю макет на глаз

Херачу

Профит

скачивать изображения всё-таки придётся – хотя бы по одному, во временную папку, чтобы загрузить в ВК и удалить у себя по окончании загрузки.

Что касается непосредственно загрузки, можно использовать cURL и его CURLFile, или, удобнее, Guzzle. Например:

$client = new \GuzzleHttp\Client;
		$resource = fopen( $tmpfile, 'r');
		$response = $client->request(
			'POST',
			$upload_url,
			[
				'multipart' => [
					[
						'name'	 => 'file',
						'contents' => $resource
					]
				]
			]
		);
		
		$uploadResult = json_decode( $response->getBody());

В БД (или быстрый кэш, типа Redis). Причин несколько:

• Ваше приложение может упасть. Игрокам не понравится, если у них вдруг пропадут карты. БД тоже падают, но вероятность этого гораздо меньше (у них больше разработчиков и тестеров).
  
• Массивы в памяти не масштабируются. Положим, пару десятков одновременных партий в памяти держать можно, но когда счет пойдет на тысячи, это будет жрать RAM, плюс тормоза на GC. А БД можно вынести на отдельный сервер и даже на отдельный кластер.
  

Ну, понятно, что в учебном примере пофиг на надежность и масштабируемость, но почему бы не делать сразу правильно?

Так же столкнулся с этой проблемой и нашёл ещё более гениальное глупое решение благодаря ответу автора:
0. Имеем VDS с пользователем admin_1 транслирующий аудио поток через remote audio. ~
1. Создаём ещё одного пользователя admin_2 на VDS и выдаём ему админские права. ~
2. Подключаемся к удалённому рабочему столу целевого VDS через пользователя admin_2. ~
3. Подключаемся к целевому же VDS средством удалённого рабочего стола из под пользователя admin_2 к пользователю admin_1. ~
4. Отключаемся от пользователя admin_2, при этом соединение admin_2 => admin_1 остаётся. ~
5. ~~~~~~~~
6. ~PROFIT~

Как итог - соединение сохраняется, устройство продолжает работать.
Плюс~плюс - покупать лишних VDS нет никакой необходимости.
Минус - инвалидная коляска, коих ещё нужно поискать.

Так нельзя.

if(q==1 || q==2 || q==3 || q==4 || q==5 || q==6 || q==7 || q==8 || q==9){

или
if([1,2,3,4,5,6,7,8,9].indexOf(q) != -1)