V
V
Vitaly Yakovenko2013-02-04 00:27:34
Java
Vitaly Yakovenko, 2013-02-04 00:27:34

Socket policy behaves uncivilized

I've been asking him for the second day, and so and so, but he does not allow connection to the server (which hangs on localhost: 6969) and that's it. The policy file is given from the same port to which the flash drive persistently but unsuccessfully tries to connect. This file is not a file at all, but the most common line of the following form:

<?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="*" secure="false"/> 
</cross-domain-policy>\0
which the server sends over the socket as soon as its client asks for it by sending <policy-file-request />\0.
I tried to figure out what the flash doesn't like. But when debugging, absolutely nothing happens. If you start the flash drive by pressing Ctrl + Enter, the connection is magically established, bypassing the policy request from the server (although the line is clearly written in the flash drive code Security.loadPolicyFile("xmlsocket://"+host+":"+port);). However, when debugging or loading a flash drive from a localhost, a situation arises when nothing happens at all. The flash drive starts up, asks for its security guards on the socket, the server sends them to it. The flash drive waits for some time, apparently considering the frailty of being a program code, and rewards me with the following information:
[SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048: Нарушение изолированной среды: file:///C|/Users/Fenx/Desktop/DrawClient/client.swf не может загрузить данные из localhost:6969."]
In general, if you have ideas about the above, please state them below what is written. Thank you all in advance for your attention.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
V
Vitaly Yakovenko, 2013-02-05
@Xazzzi

Illumination did come.
It turns out that I forgot that in non-blocking mode, when you call write (), the buffer is not sent completely to the socket. It is necessary to re-register the channel in the selector on OP_WRITE, and unsubscribe from the buffer to the socket, if possible to the end.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question