Task #1174
closedUnixStreamFace implementation
100%
Description
This task includes implementation of UnixStreamChannelFactory
, UnixStreamChannel
, and UnixStreamFace
Updated by Alex Afanasyev almost 11 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.
Updated by Junxiao Shi almost 11 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.
Updated by Davide Pesavento almost 11 years ago
- Status changed from New to In Progress
- Assignee changed from Giulio Grassi to Davide Pesavento
- % Done changed from 0 to 50
Updated by Davide Pesavento almost 11 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.
Updated by Alex Afanasyev almost 11 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.
Updated by Davide Pesavento almost 11 years ago
- Status changed from Feedback to Code review
- % Done changed from 90 to 100
Updated by Davide Pesavento almost 11 years ago
- Status changed from Code review to Closed