This forum has been archived. Please start a new discussion on GitHub.

ICE Server Thread Pool Implementation Issues


ICE uses Leader/Followers threadPool for its cuncurrency networking model, which i am very interested. After looking into the implementation codes, particullary in the "ThreadPool.cpp", some doubts come into me:

1. When the leader thread detects an event signal through select() or epoll(),
say, from the socket handle fd1, will the fd1 be removed from the "fdSet"?
As multiple threads concurrently call the select() or epool() is not allowed, the fd1 should be removed from fdSet before promoting a new leader thread, after this "only a single thread at a time to process a given handle" will be guaranteed.
Is the removal of fd1 really be done in ICE?

2. Why Promoting a new leader thread "after" the original leader has completed reading an ICE Message?
It seems that, in ICE, after detecting a pending signal in fd1, the leader thread:
(1). reads ICE message header, and then reads ICE message body.
howerver, these two process will be block sometimes, say when the Message size is so large that mutliple reads will needed.
(2). after the ICE message have been read, and before dispatching the message, the leader thread promotes a new leader thread.

a better way may be :
(1). remove fd1 from fdSet
(2). promote a new leader thread
(3). the original leader thread read ICE message and dispatches it.(so, even the original leader thread blocks when reading the ICE message, the new leader thread will still work)
(4). after the ICE message has been dispatched, inserts the fd1 into the fdSet.

Will this make sense?

Thanks a lot!

-Simon Du.


  • marc
    marc Florida
    I'm sorry, but I'm afraid explaining Ice internals is out of the scope of the support we can give here in these forums.
  • Hi, Thank you all the same!
    I just want to know whether the above point would pose any possibility to make ICE better?

    Or these are just my misunderstandings of ICE?

    Thank you very much:)
  • marc
    marc Florida
    No, it would not improve Ice, because your assumptions are incorrect. Ice does not block when reading data. All the reading in the thread pool is done non-blocking.

    With your proposed design, it would be quite easy to stage a denial-of-service attack on a server: simply have a client send several incomplete messages. Then all the threads from the thread pool would eventually block to wait for the client to finish the partial messages. This wouldn't even have to be a deliberate denial-of-service attack. Clients connecting over a slow connection could have the same effect and bring a server to a halt or slow it down so much that it becomes unusable.

    Anyway, as I said, we really cannot explain Ice internals here in these forums, so I'm afraid if you need more information, you have to experiment with this for yourself :)