From: <ya...@mi...> - 2010-08-12 08:44:19
|
Hello, I'm a big fan of yaws and Erlang! I have a problem about websocket implementation. yaws_api:websocket_unframe_data/1 fails sometime. websocket_unframe_data(DataFrameBin) -> {ok, Msg, <<>>} = yaws_websockets:unframe_one(DataFrameBin), Msg. I found return value of unframe_one/1 contains binary data at 3rd element that is not empty. This data may contains following frames. I think I need a function like this. websocket_unframe_all(DataFrameBin) -> yaws_websockets:unframe_all(DataFrameBin, []). But when use this, I need to loop through list of frames each time I receive a socket. Does anyone have more smart solution deal with this problem? -- Mitsuji, Takamasa |
From: Davide M. <ne...@gm...> - 2010-08-13 01:44:08
|
Hi Takamasa, Some comments below. :) On Thu, Aug 12, 2010 at 9:17 AM, ya...@mi... <ya...@mi...> wrote: > Hello, I'm a big fan of yaws and Erlang! > > I have a problem about websocket implementation. > yaws_api:websocket_unframe_data/1 fails sometime. > > > websocket_unframe_data(DataFrameBin) -> > {ok, Msg, <<>>} = yaws_websockets:unframe_one(DataFrameBin), > Msg. > > > I found return value of unframe_one/1 contains > binary data at 3rd element that is not empty. > This data may contains following frames. > I don't recall the rationale involved in coding yaws_api:websocket_unframe_data/1 like that but it might be that that was the expected return value in the protocol (back at that time). At this point the reference I used is no longer accessible: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-26 :\ > > I think I need a function like this. > > > websocket_unframe_all(DataFrameBin) -> > yaws_websockets:unframe_all(DataFrameBin, []). > > > But when use this, I need to loop through list of frames > each time I receive a socket. > > Does anyone have more smart solution deal with this problem? > Since the first implementation there have been some updates to the protocol: http://axod.blogspot.com/2010/06/websocket-gets-update-and-it-breaks.html The behaviour you are encountering might be the result of a more recent websockets implementation by the browser's end. Which browser are you using? I won't be able to help you sort this out at this point but hopefully other mailing list lurkers can lend an hand and/or step in and update the current implementation. ;) Best regards, Davide :) > > -- > Mitsuji, Takamasa > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: <ya...@mi...> - 2010-08-13 08:05:23
|
Hi Davide, Thank you for your response. >websocket_unframe_data/1 like that but it might be that that was the expected >return value in the protocol (back at that time). The protocol is still unstable. So it's difficult and somtime meaningless to catch up with the latest draft. I can sympathize with you there. ;) And I wish if I could make some contributions. >The behaviour you are encountering might be the result of a more recent >websockets implementation by the browser's end. >Which browser are you using? Every browser I use is very new. I encountered the behaviour when using following browsers. On safari, it could happen more often. + Safari 5.0.1 on Mac OS X 10.6.4 + Safari 5.0 on Mac OS X 10.6.4 + Chrome 5.0.375.126 on Windows XP SP3 + gimite's web-socket-js on Flash Player 10 *For IE and Firefox, I use the client implemented by flash sockets. http://github.com/gimite/web-socket-js >I won't be able to help you sort this out at this point but hopefully other >mailing list lurkers can lend an hand and/or step in and update the current >implementation. ;) I tried to write a patch dealing with 'Sec-Websocket-Key1' and other new headers. :) http://mitsuji.org/software/yaws/yaws_websockets.patch Thank you, -- Mitsuji, Takamasa >Hi Takamasa, > >Some comments below. :) > >On Thu, Aug 12, 2010 at 9:17 AM, [a:mailto:ya...@mi...]ya...@mi... ><[a:mailto:ya...@mi...]ya...@mi...> wrote: >> Hello, I'm a big fan of yaws and Erlang! >> >> I have a problem about websocket implementation. >> yaws_api:websocket_unframe_data/1 fails sometime. >> >> >> websocket_unframe_data(DataFrameBin) -> >> {ok, Msg, <<>>} = yaws_websockets:unframe_one(DataFrameBin), >> Msg. >> >> >> I found return value of unframe_one/1 contains >> binary data at 3rd element that is not empty. >> This data may contains following frames. > > >I don't recall the rationale involved in coding yaws_api: >websocket_unframe_data/1 like that but it might be that that was the expected >return value in the protocol (back at that time). >At this point the reference I used is no longer accessible: [a:http://tools. >ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-26]http://tools.ietf. >org/html/draft-hixie-thewebsocketprotocol-66#page-26 :\ > >> >> I think I need a function like this. >> >> >> websocket_unframe_all(DataFrameBin) -> >> yaws_websockets:unframe_all(DataFrameBin, []). >> >> >> But when use this, I need to loop through list of frames >> each time I receive a socket. >> >> Does anyone have more smart solution deal with this problem? > > >Since the first implementation there have been some updates to the protocol: >[a:http://axod.blogspot.com/2010/06/websocket-gets-update-and-it-breaks.html] >http://axod.blogspot.com/2010/06/websocket-gets-update-and-it-breaks.html >The behaviour you are encountering might be the result of a more recent >websockets implementation by the browser's end. >Which browser are you using? > >I won't be able to help you sort this out at this point but hopefully other >mailing list lurkers can lend an hand and/or step in and update the current >implementation. ;) > >Best regards, >Davide :) > >> >> -- >> Mitsuji, Takamasa >> >> >> --------------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >[a:http://p.sf.net/sfu/RIM-dev2dev]> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Erlyaws-list mailing list >[a:mailto:Erl...@li...]> Erl...@li...urceforge. >net >[a:https://lists.sourceforge.net/lists/listinfo/erlyaws-list]> https://lists. >sourceforge.net/lists/listinfo/erlyaws-list > |
From: Steve V. <vi...@ie...> - 2010-08-28 01:31:42
|
2010/8/12 Davide Marquês <ne...@gm...>: > I won't be able to help you sort this out at this point but hopefully other > mailing list lurkers can lend an hand and/or step in and update the current > implementation. ;) Dominique Boucher has stepped up to the plate and updated websockets for us. I just pushed the changes to github a few minutes ago. Thanks, Dominique. --steve |
From: Davide M. <ne...@gm...> - 2010-08-29 11:48:31
|
2010/8/28 Steve Vinoski <vi...@ie...> > 2010/8/12 Davide Marquês <ne...@gm...>: > > I won't be able to help you sort this out at this point but hopefully > other > > mailing list lurkers can lend an hand and/or step in and update the > current > > implementation. ;) > > Dominique Boucher has stepped up to the plate and updated websockets > for us. I just pushed the changes to github a few minutes ago. Thanks, > Dominique. > > --steve > Ahhh! The beauty of open source. :) Nice work! Cheers, Davide :) |
From: Mitsuji, T. <ya...@mi...> - 2010-08-29 23:58:39
|
Hi, 2010/8/28 Steve Vinoski <[a:mailto:vi...@ie...]vi...@ie...> >2010/8/12 Davide Marquês <ne...@gm...>: >> I won't be able to help you sort this out at this point but hopefully other >> mailing list lurkers can lend an hand and/or step in and update the current >> implementation. ;) > >Dominique Boucher has stepped up to the plate and updated websockets >for us. I just pushed the changes to github a few minutes ago. Thanks, >Dominique. > >--steve Thank you Dominique. Thank you Steve, Davide and everyone. :) It seems much better than my experimental patch. I tested it on my application, and safri 5.0.1 works fine. Now, we have no reason to be afraid of mac users and "draft 76". ;) But in my test, yaws_api:websocket_unframe_data/1 still fails sometime. I think this is problem of other part of yaws. ??? And I have an idea about usage of md5. On my windows environment, crypto:md5_xxx fails because of an absence of openssl(ssh?). So I think it better to use erlang:md5/1 like this. challenge(Key1, Key2, Challenge) -> % BinaryAnswer = % crypto:md5_final( % crypto:md5_update( % crypto:md5_init(), % digits32(Key1) ++ digits32(Key2) ++ Challenge)), % BinaryAnswer. erlang:md5( digits32(Key1) ++ digits32(Key2) ++ Challenge ). Thank you, -- Mitsuji, Takamasa |
From: Steve V. <vi...@ie...> - 2010-08-30 01:09:36
|
2010/8/29 Mitsuji, Takamasa <ya...@mi...>: > > But in my test, > yaws_api:websocket_unframe_data/1 still fails sometime. > I think this is problem of other part of yaws. ??? Can you provide more details? > And I have an idea about usage of md5. > On my windows environment, crypto:md5_xxx fails because of > an absence of openssl(ssh?). > So I think it better to use erlang:md5/1 like this. > > > challenge(Key1, Key2, Challenge) -> > % BinaryAnswer = > % crypto:md5_final( > % crypto:md5_update( > % crypto:md5_init(), > % digits32(Key1) ++ digits32(Key2) ++ Challenge)), > % BinaryAnswer. > erlang:md5( digits32(Key1) ++ digits32(Key2) ++ Challenge ). I believe crypto:md5 calls are faster than erlang:md5, sometimes significantly so. On my 3+ year old Core 2 Duo Linux box the three crypto calls combined are twice as fast as the single erlang:md5 call, for example. But maybe it's not a huge deal for this situation. I guess I'd like to hear from Davide or Dominique as to whether just using erlang:md5 as you've suggested is OK before proceeding. --steve |
From: Dominique B. <dom...@nu...> - 2010-08-30 01:41:41
|
On 10-08-29 09:09 PM, Steve Vinoski wrote: > 2010/8/29 Mitsuji, Takamasa<ya...@mi...>: >> But in my test, >> yaws_api:websocket_unframe_data/1 still fails sometime. >> I think this is problem of other part of yaws. ??? > Can you provide more details? I experienced the problem too. Sometimes there are 2 (or more) messages received from the socket while websocket_unframe_data expects a single one. I think it would be best to call yaws_websocket:unframe_all instead of yaws_websocket:unframe_one. At least that's what I did in one of my applications. But there was also a case where websocket_unframe_data was called with an incomplete message (one that did not start with 0 and end with 255). Since this happened only once, I was not what the real cause was. >> And I have an idea about usage of md5. >> On my windows environment, crypto:md5_xxx fails because of >> an absence of openssl(ssh?). >> So I think it better to use erlang:md5/1 like this. >> >> >> challenge(Key1, Key2, Challenge) -> >> % BinaryAnswer = >> % crypto:md5_final( >> % crypto:md5_update( >> % crypto:md5_init(), >> % digits32(Key1) ++ digits32(Key2) ++ Challenge)), >> % BinaryAnswer. >> erlang:md5( digits32(Key1) ++ digits32(Key2) ++ Challenge ). > I believe crypto:md5 calls are faster than erlang:md5, sometimes > significantly so. On my 3+ year old Core 2 Duo Linux box the three > crypto calls combined are twice as fast as the single erlang:md5 call, > for example. But maybe it's not a huge deal for this situation. I > guess I'd like to hear from Davide or Dominique as to whether just > using erlang:md5 as you've suggested is OK before proceeding. > > --steve I don't have a strong opinion on this one. Steve, you have more experience with Erlang than me. But if portability is really an issue, maybe the change is worth it. Dominique |
From: Steve V. <vi...@ie...> - 2010-09-01 05:37:29
|
On Sun, Aug 29, 2010 at 9:23 PM, Dominique Boucher <dom...@nu...> wrote: > On 10-08-29 09:09 PM, Steve Vinoski wrote: >> >> 2010/8/29 Mitsuji, Takamasa<ya...@mi...>: >>> >>> And I have an idea about usage of md5. >>> On my windows environment, crypto:md5_xxx fails because of >>> an absence of openssl(ssh?). >>> So I think it better to use erlang:md5/1 like this. > > I don't have a strong opinion on this one. Steve, you have more experience > with Erlang than me. But if portability is really an issue, maybe the change > is worth it. OK, I've gone ahead and changed this to use erlang:md5. thanks, --steve |
From: Wes J. <com...@gm...> - 2010-09-09 15:56:12
|
2010/8/27 Steve Vinoski <vi...@ie...>: > 2010/8/12 Davide Marquês <ne...@gm...>: >> I won't be able to help you sort this out at this point but hopefully other >> mailing list lurkers can lend an hand and/or step in and update the current >> implementation. ;) > > Dominique Boucher has stepped up to the plate and updated websockets > for us. I just pushed the changes to github a few minutes ago. Thanks, > Dominique. > > --steve I have been using websockets in yaws for several months and it has worked fine until safari was updated to 5.0.2 and chrome was updated to 6.x. I would get this error: =ERROR REPORT==== 8-Sep-2010::13:40:36 === Error in process <0.93.0> with exit value: {{badmatch,nomatch},[{yaws_websockets,unframe_one,1},{yaws_websockets,unframe_all,2},{yaws_api,websocket_receive,1},{stu_endpoint,websocket_owner,0}]} I then remembered that there was some discussion on this and found this thread. I git cloned yaws from github and there is now no error. Thx for fixing this! (firefox is still useless with websockets - their excuse is that the standard is not set in stone well enough for them to even try...) -wes |
From: Dominique B. <dom...@nu...> - 2010-09-09 15:59:34
|
On 10-09-09 11:56 AM, Wes James wrote: > Thx for fixing this! (firefox is still useless with websockets - their > excuse is that the standard is not set in stone well enough for them > to even try...) > > -wes Firefox is not completely useless. Firefox 4 (beta) now supports websockets, otherwise you can use the websocket-js project to emulate WebSocket clients in Flash. http://github.com/gimite/web-socket-js/ I tested it with Yaws while implementing support for ws-v76, and it worked flawlessly. Dominique |
From: Fred D. <fr...@du...> - 2010-09-09 17:37:17
|
Not to flame, but I find firefox useless, period. I'd guess they'd use the same excuse for the rest of html5 [1]. If pressed, they'd probably use it for all their memory leaks, too. <ducks> -Fred [1] http://html5readiness.com On Sep 9, 2010, at 11:56 AM, Wes James <com...@gm...> wrote: > Thx for fixing this! (firefox is still useless with websockets - their > excuse is that the standard is not set in stone well enough for them > to even try...) |
From: Wes J. <com...@gm...> - 2010-09-09 18:55:54
|
2010/9/9 Fred Dushin <fr...@du...>: > Not to flame, but I find firefox useless, period. > > I'd guess they'd use the same excuse for the rest of html5 [1]. If pressed, they'd probably use it for all their memory leaks, too. <ducks> > > -Fred > > [1] http://html5readiness.com That's an interesting site. I saw that 3d transforms were not support by chrome 5. I have chrome 6 and this page seemed to work: http://sebleedelisle.com/2010/03/html5-canvas-3d-particle/ I just test on safari 5.02 and it works too. Probably makes sense, since they both use webkit. Looking back at the html5readiness site safari 5 was the only one that was working with 3d. -wes |