search

google-code-backups / sabreamf

Automatically exported from code.google.com/p/sabreamf
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Unsupported command opperation 12 #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
See attached charles dump

Original issue reported on code.google.com by stoica.i...@gmail.com on 28 Apr 2008 at 6:48

Attachments:

GoogleCodeExporter commented 8 years ago 
Operation 12 is not known to me.. what did you do exactly to make this appear?

Original comment by evert...@gmail.com on 28 Apr 2008 at 7:04

GoogleCodeExporter commented 8 years ago 
Just checked with the PyAMF guys.. its new to them too..

These were the operations times known to me (from documentation)
http://code.google.com/p/sabreamf/source/browse/trunk/SabreAMF/AMF3/CommandMessa
ge.php

SabreAMF supports the PING and LOGIN command.. So i'm pretty curious what this 
is from.

Original comment by evert...@gmail.com on 28 Apr 2008 at 7:18

GoogleCodeExporter commented 8 years ago 
I don't know if that charles dump is the right thing, but what i did was a 
consequent
request of a remote method, without waiting for the result and that's the error 
i've got.

I will try to repeat it asap and give you feedback.

Original comment by stoica.i...@gmail.com on 29 Apr 2008 at 3:45

GoogleCodeExporter commented 8 years ago 
I've attached all the charles dumps needed to hopefully understand what is the 
issue,
they appeared in Charles in the order of the name of the files.

dump-1.chls
dump-2.chls

I hope they will help you.

Original comment by stoica.i...@gmail.com on 1 May 2008 at 1:26

Attachments:

GoogleCodeExporter commented 8 years ago 
looks like Flex3 adds two new CommandMessage operations:

DISCONNECT_OPERATION : This operation is used to indicate that a channel has
disconnected. 

MULTI_SUBSCRIBE_OPERATION : Used by the MultiTopicConsumer to 
subscribe/unsubscribe
for more than one topic in the same message.

(see 
http://livedocs.adobe.com/flex/3/langref/mx/messaging/messages/CommandMessage.ht
ml)

According to the ASDoc for DISCONNECT_OPERATION:

"Disconnects from the remote destination.  Because this channel uses a 
stateless HTTP
connection, it sends a fire-and-forget message to the server as it disconnects 
to
allow the server to shut down any session or other resources that it may be 
managing
on behalf of this channel."

I guess then a response is not required.  Right now it's responding with a 
fault, so
that can be avoided (and probably respond with nothing).  The PyAMF guys are
responding with what looks like a null result (http://pyamf.org/ticket/325).

The following patch takes a similar approach to the PyAMF implementation.  I
wondering if it would be more efficient to drop the connection and respond with 
nothing.

Original comment by michael....@henryschein.com on 8 Jul 2008 at 1:55

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks a lot, this fix has been committed to SVN. A release will follow within 
a week..

Original comment by evert...@gmail.com on 16 Sep 2008 at 10:51

GoogleCodeExporter commented 8 years ago

Original comment by evert...@gmail.com on 16 Sep 2008 at 10:52