Let us use a sample situation, where the sender machine ("Sender")sends three
messages (GIOP) in rapid succession to the receptor machine ("Receptor"): first
message of 36 bytes, second message of 982 bytes, third message of 1062 bytes.
The Receptor initially has no data waiting on the socket, and timing makes it
so it only performes the next recv() after all three has no data waiting on the
socket, and timing makes it so it only performes the next recv() after all three
mentioned messages have arrived. Here's what happens:

1. In the first 1024-byte read (recv()) in Transport::input_handle_i(), the
Receptor will read the first two messages entirely, plus 6 bytes of the
third message (i.e. less than the 12 bytes required for the header).
Nevertheless, the incomplete message is stored in a node in the queue tail.

2. The Receptor processes the first two messages from the input queue. The
incomplete third message thus becomes the new queue head. Since it is
incomplete, the Receptor reads a new 1024-byte chunk through
recv() in Transport::handle_input_i().

3. Immediately after the recv(), Transport::handle_input_i() calls
Transport::parse_consolidate_messages(), who calls
Transport::parse_incoming_messages(). Since the tail is incomplete, this does
nothing and returns 0

3. Back in Transport::parse_consolidate_messages(), the call to
Transport::missing_data() returns -1 since the header is incomplete and there is
no payload size information yet. As a result,
Transport::consolidate_extra_messages() is called

4. Transport::consolidate_extra_messages() extracts the node with the incomplete
message from the queue tail and calls GIOP_Message_Base::consolidate_node()

5. In GIOP_Message_Base::consolidate_node(), the section for (missing_data ==
-1) is entered. The header is completed with 6 bytes of data from the
'incoming' buffer (leaving 1018 bytes there), it is parsed, and now the node is
grown to accept the payload size.

6. We said the message, when sent, was 1062 bytes, thus 1050 bytes of payload.
Since this is greater than the 1018 bytes left in the 'incoming' buffer,
GIOP_Message_Base::consolidate_node() copies only the 1018 bytes available,
recomputes the missing_data and returns 0

7. Back in Transport::consolidate_extra_messages(), the tail is put back in the
queue and we enter the while() loop that calls
GIOP_Message_Base::extract_next_message()

8. In GIOP_Message_Base::extract_next_message(), nothing is done, since
incoming.length() is now zero, and 0 is returned.

9. Back in Transport::consolidate_extra_messages(), the while() loop is left
because of the 0 return value, and Transport::process_queue_head() is called

10. Since the message in the queue head is still incomplete,
Transport::process_queue_head() does nothing and just returns 1. This return
value is then propagated back up to Transport::handle_input_i()

11. In Transport::handle_input_i() we're thus back from the
parse_consolidate_messages() call with a return value of 1. We call
GIOP_Message_Base::get_message_data(), then, since the message has no fragments,
we call Transport::process_parsed_messages() just before exiting from
handle_input_i(). The comment just above this call says "//Now we have a full
message in our buffer". This is not true, THE MESSAGE IS STILL
INCOMPLETE AT THIS POINT, it is missing 1062 - 6 -1024 = 32 bytes.

12. In Transport::process_parsed_messages, the message type is determined to be
1 (MESSAGE_REPLY), and we begin processing it by calling
GIOP_Message_Base::process_reply_message().

13. GIOP_Message_Base::process_reply_message() calls
generator_parser->parse_reply() who returns -1 (I
guess because the message is incomplete). This causes
the connection to be closed by Transport::process_parsed_messages(), and all
messages on that socket are lost.


-------------------------------------------------------------------
This is one path to the problem. Thanks to D D <d_e_r_a_n_2@yahoo.com> for
reporting this. Looks like Chris Cleeland may be seeing a similar problem.