Я работал с флеш-сокетами и настроил сервер в C / Linux. У меня проблемы с получением части запроса файла политики. Я видел другие посты на SO и проверял сайт Adobe, но у меня все еще есть некоторые проблемы.
На моем сервере после принятия соединения я получаю <policy-file-request/>. Я использую следующий файл политики XML.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" to-ports="*"/>
</cross-domain-policy>
Я просто помещаю весь файл в массив символов и затем записываю его через тот же порт, на который поступил запрос (я не использую 843, а пользовательский порт). Я читал, что это должно заканчиваться нулевым байтом (это означает NULL или '\ 0'?). Я не могу пройти эту часть.
На стороне клиента у меня есть прослушиватель событий сокета, такой как
sock.addEventListener(ProgressEvent.SOCKET_DATA, sockFunc);
но событие никогда не запускается.
Чтобы усугубить проблему, мне кажется, что Chrome не нравится отладка Flash, и когда я использую IE или FF, мой сервер просто блокирует recv и никогда не получает <policy-file-request/>. Я предполагаю, что на IE и FF он пытается порт 843, а затем просто сдается? Это плохая практика, чтобы попытаться отправить файл политики через пользовательский порт?
Любая помощь будет очень цениться. Я действительно застрял здесь: (
EDIT:
С добавлением нулевого байта в конец мой сервер теперь принимает соединение, читает запрос политики, записывает файл политики через сокет, затем снова принимает и блокирует на recv. Принять должна быть блокировка, так как сейчас я пытаюсь подключить только одного клиента. Предполагается ли клиент восстановить соединение с новым файловым дескриптором после правильного получения файла политики? На клиенте я пытаюсь написать на сервер с
sock.writeUTFBytes("Hello");
sock.flush();
но он, очевидно, никогда не добьется этого, поскольку recv блокирует.