Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000153Taste[All Projects] PolyORB-HI-Allpublic2011-06-04 20:142021-09-16 12:50
Reporterhugues 
Assigned Tomaxime 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Summary0000153:

Size of requests sent/received is too high

Description

Hi,

This is a follow up to a previous commit by Julien a while back in PolyORB-HI/C, but also a long standing design choice in PolyORB-HI/Ada.

By construction, the size of the packets sent are __PO_HI_MESSAGES_MAX_SIZE, that is the maximum size of all messages to be sent.

This design choice is unfortunate; as it is sub-optimal in terms of bandwidth (but ease analysis).

Question is: shall we change implementation to use actual size of the message to be sent, that is sizeof (header) + sizeof (payload) ?

Pro: yes, we should to be efficient

Con: will break several things

PolyORB-HI/Ada is designed so that the size of the request is marshalled, so this is complex, but not feasible. For PolyORB-HI/C, I do not know the cost

Yet, my feeling is that we should do it, but I delegate the decision to Julien and Maxime. This is inline with the other note on ticket on ASN.1 protocol marshalling

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000759)
maxime (administrator)
2011-06-06 19:03

I assume that you are only talking about messages sent between entities in a distributed system.

In that case, when using the ASN.1 encodings, message will be of different sizes by construction.

Between two communicating entities, there shall be a single ASN.1 message defined, of the form:

Packet-Between-A-and-B ::= SEQUENCE {
from Entity-Id,
to Entity-Id,
payload CHOICE {
msg1 OCTET STRING (SIZE (XXX)),
msg2 OCTET STRING (SIZE (YYY)),
...
}
}

The content of the CHOICE construct is the list of possible messages carried through the given channel. It is using an OCTET STRING type as it is already encoded. The size XXX or YYY is known.

The receiver knows it can receive only a message of the type "Packet-Between-A-and-B" so it will be able to decode it using ASN1Scc decoders, whatever its size.

Does it make sense?

(0000763)
hugues (administrator)
2011-06-07 06:55

It does, but does not answer my question
Currently, irrespective of what ASN.1 marshallers do, both runtimes send buffers whose size is the maximum of all elements being sent.

This is this behavior that worries my. Let me illustrate

camera <-> compression CPU <-> earth

camera is sending a big picture
CPU is compressing it, sending it to earth

even with compression enabled, earth will received a packet whose size is that of the packet sent from the camera to the CPU

so this is inefficient

question is: shall we trash it?
given the way I word it, I expect yes, then this calls for comments on ticket 4

(0001920)
maxime (administrator)
2012-09-10 10:07

I would say that whenever we manage to have PUS-format enabled for the distributed communication, we will have a fixed header containing the packet size at a a place that is always the same, so we will be able to block only first for the header size (fixed-sized), then decode it to get the size, and then wait only for the remaining bytes. In that case we don't have to always send the biggest packet as we do today.

(0003800)
maxime (administrator)
2021-09-16 12:50

No update since 2012, time to close.
Issues with big messages are dealt with in the branch feature_bigMessage that is based on TASTE10


- Issue History
Date Modified Username Field Change
2011-06-04 20:14 hugues New Issue
2011-06-04 20:14 hugues Status

new => assigned

2011-06-04 20:14 hugues Assigned To

=> maxime

2011-06-06 19:03 maxime Note Added: 0000759
2011-06-07 06:55 hugues Note Added: 0000763
2012-09-10 10:07 maxime Note Added: 0001920
2021-09-16 12:50 maxime Note Added: 0003800
2021-09-16 12:50 maxime Status

assigned => closed

2021-09-16 12:50 maxime Resolution

open => won't fix



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker