Даже в определениях идиотизма встречается идиотизм.
Цитата:
Идиотизм — устаревшее название идиомы
Идиома в программировании — понятие близкое к понятию шаблона проектирования. Идиомы представляют собой шаблоны проектирования, учитывающие специфику конкретного языка программирования и потому не универсальные. Это хорошие решения проектирования для конкретного языка или программной платформы.
Идиома в программировании — понятие близкое к понятию шаблона проектирования. Идиомы представляют собой шаблоны проектирования, учитывающие специфику конкретного языка программирования и потому не универсальные. Это хорошие решения проектирования для конкретного языка или программной платформы.
Идиотизмы: Socket
для понимания материала необходимы следующие знания:
flash.net.Socket
Подключение к сокетам
ну вот за что флэшерам такие мучения? Socket, казалось, ну что можно сломать в таком примитивном классе? анннет.
и так.
1. мы пытаемся законектися.
2. допустим наш сервер лежит.
3. нам само сабой вываливается ioError.
4. мы, узнав о такой трагедии, расстраиваемся и отписываемся от всех событий.
5. получаем unhadled securityError, так как policy-file нам тоже не удалось получить.
замечательно! вот только с откуда я могу знать, что после ioError я 100% получу securityError? а если у меня на 843 порту ещё один демон болтается? мне на всегда события оставлять висеть? до здравствуют утечки?
исправленный класс Socket:
package blooddy.patch.net { import flash.events.ErrorEvent; import flash.events.Event; import flash.events.IOErrorEvent; import flash.events.SecurityErrorEvent; import flash.net.Socket; /** * @author BlooDHounD * @version 1.0 * @playerversion Flash 9 * @langversion 3.0 */ public class Socket extends flash.net.Socket { //-------------------------------------------------------------------------- // // Constructor // //-------------------------------------------------------------------------- /** * @inheritDoc */ public function Socket(host:String=null, port:int=0.0) { super( host, port ); super.addEventListener( Event.CLOSE, this.handler_close, false, int.MAX_VALUE, true ); super.addEventListener( IOErrorEvent.IO_ERROR, this.handler_error, false, int.MAX_VALUE, true ); super.addEventListener( SecurityErrorEvent.SECURITY_ERROR, this.handler_error, false, int.MAX_VALUE, true ); } //-------------------------------------------------------------------------- // // Variables // //-------------------------------------------------------------------------- /** * @private */ private var _hasError:Boolean = false; //-------------------------------------------------------------------------- // // Overrided methods: Socket // //-------------------------------------------------------------------------- /** * @inheritDoc */ public override function connect(host:String, port:int):void { super.connect( host, port ); this._hasError = false; } /** * @inheritDoc */ public override function close():void { super.close(); this._hasError = true; } //-------------------------------------------------------------------------- // // Event handlers // //-------------------------------------------------------------------------- /** * @private */ private function handler_close(event:Event):void { this._hasError = true; } /** * @private */ private function handler_error(event:ErrorEvent):void { if ( this._hasError ) { // ошибка уже была. поэтому блокируем остальные event.stopImmediatePropagation(); } else { this._hasError = true; // надо оптисаться, что бы не мешать вызову исключения super.removeEventListener( event.type, this.handler_error ); if ( !super.hasEventListener( event.type ) ) { // если подписчиков нету, диспатчим ошибку, что бы вывалился unhadled securityError super.dispatchEvent( event ); } // подписываемся обратно super.addEventListener( event.type, this.handler_error, false, int.MAX_VALUE, true ); } } } }
Всего комментариев 60
Комментарии
23.04.2010 16:31 | |
Цитата:
допустим наш сервер лежит.
Цитата:
мы, узнав о такой трагедии, расстраиваемся и отписываемся от всех событий.
|
23.04.2010 16:32 | |
конечно. нечего держать сокет в памяти. вывалили сообщение юзеру и удали весь контроллер с сокетом.
|
23.04.2010 16:46 | |
Так сервер может очухаться через минуту или через 5.
Можно пойти тремя путями: 1. Переключиться на другой "канал" обмена данными. Тогда да, тут это нужно. 2. Ждать до упора, то есть время от времени пытаться подконнектиться. 3. Делаем пункт 1, но при этом не прекращаем попыток пункта 2 и при удаче переходим на сокет. То есть, в 2 из 3 случаев отписываться не надо. А оставшийся, на мой взгляд не очень хороший подход, пункт 3 мне больше нравится. |
|
Обновил(-а) iNils 23.04.2010 в 16:58
|
23.04.2010 17:01 | |
То есть тебя не устраивает, что ты не только получаешь IOErrorEvent.IO_ERROR, но SecurityErrorEvent.SECURITY_ERROR после?
|
23.04.2010 17:21 | |
угу. именно так я и написал =)
|
23.04.2010 17:22 | |
Возможно в этом есть какой-то смысл, который мы пока не видим?
|
23.04.2010 17:26 | |
ага. истина где-то рядом =) это не про adobe
|
30.11.2010 21:53 | |
от того что 843 порт закрыт, у вас не будет вываливаться IO_ERROR. так что ваша логика не имеет отношения к реальным вещам.
|
30.11.2010 23:02 | |
Цитата:
2. допустим наш сервер лежит.
|
30.11.2010 23:58 | |
и? ioError вываливается не из-за того что закрыт 843 порт.
|
11.04.2011 16:53 | |
Кстати, обрати внимание на тип первого параметра DataOutput.writeBytes()
Я ток что обламался так неплохо... |
11.04.2011 22:00 | |
ByteArray первым параметром идет. В чем проблема возникла?
|
12.04.2011 12:19 | |
я не знаю как объяснить, но ты не прав. основной смысл в том, что из IDataOutput нельзя прочитать данные. а значит записывать их туда бессмысленно с точки зрения сокета.
|
12.04.2011 14:14 | |
у нас нет потоков. кстати копирование в системе происходит через кэширование в памяти.
|
12.04.2011 17:55 | |
Все нормальные языки на "высоком" уровне офромляют запрос к D-Bus или похожему сервису и он занимается копированием. Это если мы говорим о файловой системе / копировании файлов.
В Шарпе это нормально прочитать из потока и тут же записать в другой http://msdn.microsoft.com/en-us/library/dd782932.aspx обрати внимание. Я так предполагаю, что в Яве тож наверное до этого додумались, ну и т.п. Это тривиальная задача которая возникает практически в любом более-менее большом десктопном приложении, тут как бы даже спорить странно... |
12.04.2011 19:35 | |
ну они молодцы. заменили класс ByteArray на класс Stream. что-то интерфейсом и там не пахнет ...
просто из-за синхронности они в следующей строчке могут сразу заполучить вычитанный полностью стрим. |
|
Обновил(-а) BlooDHounD 12.04.2011 в 19:38
|
12.04.2011 19:39 | |
и ещё я не понял какая разница, кто буферизирует данные, D-Bus или кто-то ещё, если это всё равно происходит.
|
12.04.2011 21:13 | |
Я за идею Олега. Очень здраво.
|
12.04.2011 21:15 | |
ну перестроить мир очень легко =) всё в ваших руках.
|
12.04.2011 21:16 | |
к тому же если вам очень припёрло, то есть такая штука как наследование. допишите и наслаждайтесь.
|
13.04.2011 03:02 | |
dimarik, ByteArray реализует эти интерфейсы для твоего дополнительного удобства. на самом деле в первую очередь он является обычным массивом байт. тобишь обычный byte[].
|
13.04.2011 03:41 | |
у меня нет слов =) смешались в кучу люди, кони ... я даже не знаю в чём я упрямлюсь, если из нас двоих от первоначальной темы удалился ты, причём максимально возможную дистанцию моей некомпетентности. вместо рассуждений научи меня в сях читать файл без буфера =) у нас вопрос буфера стоял изначальный? ты же хочешь сэкономить процессорное время тем, что флэш будет делать bytes.writeByte( value ) вместо bytes[i] = value? исходя из твоих суждений именно этим мы и сэкономим процессорное время добавил 100500 вызовов чёртки-каких методов =)
|
|
Обновил(-а) BlooDHounD 13.04.2011 в 03:57
|
13.04.2011 14:19 | |
wvxvw, ты какой-то бред несёшь. перечитай всё с самого начала. чего хотел ты в первых постах, и чего ты хочешь сейчас. у тебя спор ушёл в область полемики, где совершенно не говоришь по теме. я тебе это об этом говорю уже 4й пост, но ты ещё больше углубляешься в теологию. в общем совершенно потерял нить твоей мысли. всё что понял:
1. ты хочешь многопоточность 2. ты хочешь стрим ( мегасуперпуперстрим из шарпа, который всемогущ и супер быстр ) 3. наличие IDataOutput в readBytes тебе побоку. |
|
Обновил(-а) BlooDHounD 13.04.2011 в 14:58
|
13.04.2011 14:57 | |
Почитал, не удержался вклиниться, пардон.
Как-то я делал такой экперимент со свои расширением проектора: Код:
var f:PFile = new PFile(); f.create("d:\\video\\vvv.avi"); var t:PFile = new PFile(); t.create("d:\\video\\vvv2.avi"); var size:uint = f.size; var offset:uint = FlrunEx.MEMSIZEMAX/2; for (var i:uint = 0; i < size; i += offset) { var b:ByteArray = f.readBytes(offset); t.writeBytes(b); } var d:ByteArray = f.readBytes(size-i); t.writeBytes(d); f.close(); t.close(); К чему я все это говорю? Сдается, что при работе с файлами, традиционной, так скажем, т.е. через буфер, накладные расходы на обслуживание каких-то там writBytes() в АС - семечки. Что уж говорить про memory stream'ы... там вообще различия будут копеешные. Ну, а предмет спора - почему не сделали чтени-запись в ас как в c# (через нативы и т.п., о чем говорил Олег), это для ниши плеера на рынке приложений просто ни к чему, сейчас, вовсяком случае. С сокетами вопроса вообще не понял, там все асинхронно по определению. И еще, Олег, а ты не смешиваешь понятия stream (поток) и thread (тоже поток)? ЗЫ. На чистом АС я так не пробовал, в АЙР, скажем, потому не судите строго |
|
Обновил(-а) alexcon314 13.04.2011 в 15:03
|
13.04.2011 18:48 | |
wvxvw, я уже не знаю как ещё спросить: ну ты же понимаешь, что работа через методы интерфейса будет в 100 раз медленнее нежели это происходит сейчас?
и что в твоём понимании рантайм? это ты типа VM так обзываешь? |
|
Обновил(-а) BlooDHounD 13.04.2011 в 19:04
|
Последние записи от BlooDHounD
- Обновление blooddy_crypto.swc до версии 0.5.1 (31.03.2016)
- Кто не успел - тот опоздал (19.04.2011)
- Обновление blooddy_crypto.swc до версии 0.3.1 (29.11.2010)
- blooddy_crypto.swc теперь умеет JSON (13.10.2010)
- Загадочный CommaExpression (06.09.2010)