Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved on uxr_close_tcp_platform() to avoid potentially losing bytes in flight. #97

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

sp193
Copy link

@sp193 sp193 commented Jul 3, 2019

This is similar to the third point mentioned in my new PR within the Agent repository.

This revolves around the fact that send() does not guarantee that the receiver will receive all data. By waiting for the other side (the agent in this case) to also close the connection, we can be sure that all data that should have been received, was received.
This also solves another problem: under such a condition, calling close() on the socket() will result in the remote end sending a TCP RST in response to the FIN-ACK.

@richiware
Copy link
Member

Build status:

  • Linux Build Status
  • Windows Build Status

@sp193
Copy link
Author

sp193 commented Oct 6, 2019

The error was "ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from https://github.com/eProsima/Micro-XRCE-DDS-Client.git"

@richiware
Copy link
Member

Build status:

  • Linux Build Status
  • Windows Build Status

BorjaOuterelo
BorjaOuterelo previously approved these changes Nov 15, 2019
{
/* Synchronize the stream with the agent, to avoid losing bytes currently in flight. */
shutdown(platform->poll_fd.fd, SHUT_WR);
int poll_rv = poll(&platform->poll_fd, 1, 10000);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can define the 10000 ms. Why does it need to polling so long? Did you tested it or it is just a approximation?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is an approximation. You are right to say that computers would probably not need so much time, but those are under ideal conditions (no network problems, host not overloaded etc). On the other hand, if XRCE Agent encountered the socket write closure, it should follow up very soon. I think it only has to be long enough to cater for the possibility that the Agent has hung or has dropped out of contact, while not blocking the client for a needlessly long period of time.

int poll_rv = poll(&platform->poll_fd, 1, 10000);
if (0 < poll_rv)
{
char dummy;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can change it by uint8_t[64] to increase performance?

Comment on lines 42 to 59
bool rv = true;

if (INVALID_SOCKET != platform->poll_fd.fd)
{
/* Synchronize the stream with the agent, to avoid losing bytes currently in flight. */
shutdown(platform->poll_fd.fd, SD_SEND);
int poll_rv = WSAPoll(&platform->poll_fd, 1, 10000);
if (0 < poll_rv)
{
char dummy;
while (recv(platform->poll_fd.fd, &dummy, sizeof(dummy), 0) > 0) {};
}
if (0 == closesocket(platform->poll_fd.fd))
{
rv = (0 == WSACleanup());
}
}
return rv;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comments as in Linux case.

@richiware
Copy link
Member

Build status:

  • Linux Build Status
  • Windows Build Status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants