Jak nie urok to sraczka. Po sześciu godzinach, rozmowie z inou i mooską i przeczytaniu tego, stwierdziłem, że się poddaję. Wygląda na to, że nie ma żadnego sposobu na poznanie statusu bufora wyjściowego flashowego socketa. Dla bufora wejściowego, czyli danych nadchodzących mamy Socket::bytesAvailable, oraz zdarzenie ProgressEvent.SOCKET_DATA. Niestety w przeciwieństwie do informacyjnego rozpasania wejścia na wyjściu mamy biedne Socket::flush(). Żadnej informacji, że nasze dane już u dotarły do adresata (część bufora się wypróżniła ;>). Przy małej ilości danych to żaden ból, jeśli jednak w ten sposób chcemy wysłać bitmapę, czy plik i pokazać postęp to problem już jest poważny. Jeśli usługa nasłuchująca po drugiej stronie nie da nam odpowiedzi, że już wszystko zebrała, to możemy sobie czekać do usranej śmierci.
Próbowałem wszystkiego, łapania wyjątków, sprawdzania bieżącej pozycji czytanego ByteArray’a, nasłuchiwania wszystkiego co się da i na drzewo nie ucieka. Nada. Nic…
Ciekawy problem… zastanawiałem sie jak z tym zrobiono w przypadku mx:Producer i mx:Consumer. Musiałbym bawić sie w generowanie kodu ActionScriptu 3 a potem analizowanie go. Jeszcze nie doszedłem do tajnik FDS na poziomie AS3.
To może trochę nie na temat…
Otoż Producer ma tylko metodę send() i nic więcej… chyba jesteśmy w podobnej sytuacji
„Ciekawy”? ;) Boli jak wrzod na tylku. Adobe zalozyl, ze kazda wyslana wiadomosc zostanie potwierdzona. Jesli napiszemy sobie swoj serwer: „czarna dziure”, ktora nie odpowiada niczym na zakonczenie transferu, to Socket nam na nic…
To jest chyba zrozumiałe ze względu chyba, żeby programiści nie napisali klienta P2P w AS3?
A może dzielić dane na małe pakiety i flushować je, ale to wymagałoby sporo kodowania w tym serwerze „czarna dziura” ?
i co jakiś czas prowadzić nasłuch tego serwera „czarna dziura” obserwując jego „otoczenie” bo to co już przyjął serwer „czarna dziura” wpływa na inne klienty które też pobrały „małe pakiety” Ale to już mi przypomina tworzenie klientów i serwera UDP – a tego Flash Player 9 chyba nie obsługuje?
O, Michal, to by bylo proste. Jednak glowny „warunek” jest taki, ze to my jestesmy odpowiedzialni za to ile juz wyszlo. Gdyby serwer mogl zwrocic info, to nie byloby zadnego problemu… Ale w koncu na BARDZO niskim poziomie player wie ile wyslal… Jednak tam juz dostepu nie mamy:(
Pożyjemy…. może ktoś znajdzie odpowiednik ASNative() dla AS3 i FlashPlayera 9
A tak na marginesie może coś wiadomo o funkcji runABC() jako zamienniika __byte__()?
Z tego co pamietam __byte__() byla funkcja/opcja kompilatora. Taka prawie-pragma…
Szukając informacji na temat ASNative() w AS3 w Flash Playerze 9
zauważyłem że cześć kodu kompomentów Flex 2 ma w sobie
sporo odesłań typu http://livedocs.adobe.com/flex/2/langref/statements.html#native
czyżby wystarczy stosowanie
package
{
public class MyClass
{
native function trace():void;
}
}
Może zrobimy listę takich funkcji z atrybutem native?
O ile chyba nie można tworzyć własnych funkcji z atrybutem native ale można ich używać ?
Jestes pewien, ze chodzi o native? Dzisiaj przelecialem EditPlusem wszystko z SDK i nie znalazlem nic z odwolaniami native namespace. Poza Global.as oczywiscie.
Po prostu zdekompilowałem do postaci bajtkodu abc zawartość playerglobal.swc i zobaczyłem kod składający sie prawie z samych native function nazwa ()
Potem podejrzałem w zwykłym edytorze plik NPSWF32.dll i tam znalazłem listę wszystkich native function które są zaimplementowane w FlashPlayerze nawet takich dziwnych dumpHeap czy deblocking badz knockout czy MethodClosure
Można też dowiadywać sie o „ukrytych” niedokumentowanych elementach kodu poprzez refleksję przy pomocy flash.util.describeType;
Ooo flash.events.WeakMethodClosure :) Jednak nie moge soe do tego dobrac deskrajbtajpem:( Brakuje starego dobrego ASSetPropFlags.
Ale deblocking to z Video jest.
Witam, przypadkiem tu trafilem ale gadke macie przednia, nic nie kumam :D Mnie natomiast interesuje deblocking, jak i kiedy go najlepiej stosowac. Pozdrawiam!