Project

General

Profile

Actions

Task #1174

closed

UnixStreamFace implementation

Added by Alex Afanasyev about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
High
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
8.00 h

Description

This task includes implementation of UnixStreamChannelFactory, UnixStreamChannel, and UnixStreamFace

Actions #1

Updated by Alex Afanasyev about 10 years ago

  • Assignee set to Giulio Grassi
  • Start date deleted (01/30/2014)
  • Estimated time set to 8.00 h

The implementation of this face (+channel and channelfactory) should be very simple. UnixStreamFace class should be simply derived from StreamBase<boost::asio::local::stream_protocol::socket> and the few other things will be very similar to TcpFace.

ChannelFactory should be able to create UnixChannel using the supplied const std::string& unixSocketPath. UnixChannel must support listen operation and may support connect, but it is optional.

Actions #2

Updated by Junxiao Shi about 10 years ago

Alex Afanasyev wrote:

ChannelFactory should be able to create UnixChannel using the supplied const std::string& unixSocketPath. UnixChannel must support listen operation and may support connect, but it is optional.

UnixChannel should not support connect operation, because there is no clear semantic for this operation. A channel defines the local endpoint, but there isn't a named local endpoint for outgoing UNIX stream connections.

And this feature is never needed in deployment, because every host is expected to run only one forwarder.

Actions #3

Updated by Davide Pesavento about 10 years ago

  • Status changed from New to In Progress
  • Assignee changed from Giulio Grassi to Davide Pesavento
  • % Done changed from 0 to 50
Actions #4

Updated by Davide Pesavento about 10 years ago

  • Status changed from In Progress to Feedback
  • Priority changed from Normal to High
  • % Done changed from 50 to 90

There's an API problem in UnixStreamChannelFactory. Both create() overloads can take a string as their only argument, because asio::local::stream_protocol::endpoint has an implicit conversion constructor (both from const char* and std::string). As a consequence, calling e.g. UnixStreamChannelFactory::create("/foo/bar") is ambiguous.

Actions #5

Updated by Alex Afanasyev about 10 years ago

If either works the same, then we can remove one of them. For simplicity, I would remove local::Endpoint one, since people more likely to known how to deal with strings, then boost::asio.

Actions #6

Updated by Davide Pesavento about 10 years ago

Agreed.

Actions #7

Updated by Davide Pesavento about 10 years ago

  • Status changed from Feedback to Code review
  • % Done changed from 90 to 100
Actions #8

Updated by Davide Pesavento about 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF