Hi Dave,
I agree that it would be nice if we could be more intelligent about types rather than sending everything as strings. What do you think about adding a byte to each argument to indicate a data type? We currently have key/val, string, and int, but we could also add other types where it would make sense for efficiency.
Other than the corresponding routines in org.eclipse.ptp.proxy.protocol, I can't think of anywhere else in the debugger that would be impacted.
Cheers, Greg
On Mar 29, 2010, at 10:30 AM, Dave Wootton wrote:
Greg
I looked at the SDM code and think I
have additional changes on the proxy side of the connection as follows:
1) sdm_message_send serializes msg->aggregate,
msg->src and msg->dest by converting them to ASCII strings. I think
I need to convert the aggregate value to varint and the src and dest to
an array of byte data The body of the message has already been converted
to the new binary protocol by proxy_serialize_msg
2) The aggregate, src and dest need
to be converted back to int and bitset in sdm_message_progress. The body
of the message gets converted back to message header and args array form
in proxy_deserialize_msg.
3) In proxy_deserialize_msg, it looks
like each argument gets added to the args array as a string value, where
if the string represents an enumeration, the value is reconstructed as
key=value
4) DbgDeserializeEvent looks like it
is ok as-is. Converting the message from binary format to the existing
message header and array of string arguments in proxy_deserialize_msg then
parsing the message header and array of strings format into the proper
internal variables in DbgDeserializeEvent seems a little inefficient in
terms of CPU time. However, if proxy_deserialize_msg was to do anything
more intelligent, then I think each argument in the binary message format
needs to carry a type specification so it can be properly decoded. There's
probably a number of other changes elsewhere in the code if we change the
internal message structures to deserialize the message more intelligently.
These are the changes I can find by
just reading the code. There might be more that will be found as part of
actually changing the code.
Does this seem reasonable?
Dave
Yes, the debugger protocol is in org.eclipse.ptp.proxy.protocol,
and the SDM (org.eclipse.ptp.debug.sdm) uses both the proxy and utils libraries.
For the C side, take a look in src/client/client_cmds.c and src/utils/event.c.
Greg
On Mar 24, 2010, at 10:27 AM, Dave Wootton wrote:
Greg
I realized that in my rework of the client/proxy protocol I didn't consider
SDM debugger communication with the Eclipse client. Does the debugger use
the same ProxyPacket class as the proxies use, and does the SDM debugger
use the same org.eclipse.ptp.proxy and org.eclipse.ptp.utils libraries
as the proxies use? Are there other places where I should look as part
of implementing the binary proxy protocol changes?
Dave_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________ ptp-dev mailing list ptp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ptp-dev
|