Task #1174
closed
- 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.
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.
- Status changed from New to In Progress
- Assignee changed from Giulio Grassi to Davide Pesavento
- % Done changed from 0 to 50
- 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.
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.
- Status changed from Feedback to Code review
- % Done changed from 90 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF