[zeromq-dev] Problem: ipc:// does not work on Windows

Pieter Hintjens ph at imatix.com
Fri Oct 3 14:03:20 CEST 2014


I think both connect and bind have to check the file. It doesn't need
cleaning up IMO: as long as the IPC endpoints aren't duplicated. It
becomes a persistent map from endpoint to socket. Indeed, either
connect or bind can create a new entry (same algorithm: lock file,
look for entry, create one if it's missing).

Come to think of it we don't need the hashing, if we use a locked
file. Random port or sequential port, it'll all work. We should
probably use a range outside (below) the normal ephemeral range (49152
to 65535) to avoid conflicts with normal use. I'd suggest a block
before 49152.

On Fri, Oct 3, 2014 at 12:30 PM, Doron Somech <somdoron at gmail.com> wrote:
> Ok, and the client should always check the file anyway?
>
> So I think we can get rid of the cleanup, but the file can be big if it
> append only.
>
> I suggest we allocate fix size for each entry in the file, the first entry
> in the file will be the first port in the ephemeral port range, we actually
> don't need to write the port, only the address because the port is indexed.
>
> The binding socket enter the mutex and try to bind according to the hashed
> port and increase on failure, when succeeding the server write the address
> to the correct location at the file terminated by '\0' and exit the mutex.
>
> The connecting socket enter the mutex and search for the address, starting
> at the hashed location, then exit the mutex.
>
> The last question is do we want to hash or just use ephemeral port, the
> advantage of hashing is quicker search for the connecting socket but slower
> binding for the server. Using ephemeral port will be a little easier to
> implement and  quicker for the binding socket, however the connecting socket
> will have to search the entire file.
>
> On Thu, Oct 2, 2014 at 11:27 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>> How about a mix of hashing and text file? That means a given endpoint
>> will always use the same port by default, and then we can increment to
>> find a free port. This removes most/all the problems of cleaning up, I
>> think.
>>
>> On Thu, Oct 2, 2014 at 5:32 PM, Doron Somech <somdoron at gmail.com> wrote:
>> > I would go with mutex and shared file, but I think it is complicated to
>> > implement, because every time socket connects it has to check the file
>> > and
>> > cannot actually use hashing. The problems with hashing:
>> >
>> > * Try to bind and port is taken ?
>> > * Try to connect but the peer is not zeromq
>> > * Try to connect and the peer is zeromq but not the one I actually want.
>> >
>> > Because of the third problem we will have to check the file on every
>> > connect
>> > which mean we don't need the hashing, just the file.
>> >
>> > So we have a file, every time we bind we bind to ephemeral port and
>> > write a
>> > row to the file with the port and the name and every time we connect we
>> > check the file, but the remain case is when do we clear the file?
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Oct 2, 2014 at 3:12 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> >>
>> >> This is annoying mainly because it hurts code portability and also
>> >> because ipc:// (especially with abstract endpoints) is a nicer
>> >> semantic for local services than TCP ports. e.g. I've a protocol
>> >> called zccp and the default location for a zccp broker is
>> >> ipc://@/zccp.
>> >>
>> >> Solution: cheat, on Windows
>> >>
>> >> Real solution: accept "ipc://" endpoints and hash them to a socket
>> >> number in the ephemeral range, then bind/connect on 127.0.0.1 with
>> >> that port number.
>> >>
>> >> Difficulty: hash conflicts. :-)
>> >>
>> >> If anyone has a plausible solution to hash conflicts (registry?) then
>> >> this should be quite simple to make.
>> >>
>> >> -Pieter
>> >> _______________________________________________
>> >> zeromq-dev mailing list
>> >> zeromq-dev at lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list