Archived

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

Is it feasible to use IcePatch2+Gacier2?

OrNot
OrNot
in Help Center
hi,
The manu said: As with all Ice services, IcePatch2 can be configured to use Ice facilities such as
Glacier2 for firewall support and IceSSL for secure communication.( P1190 , ICE2.1.2). But I have some questions about it.

1) As I understand(I am not very sure :o ), the glacier2router will buffer the data from server. If the data is not large, such as in the chat demo,it is ok . However, If the data is from IcePatch server, the situation is very different. I think it seems impossible for glacier2router to buffer the large data ,say, 100M from icepatch,especially to deal with the concurrence issues. The memory of glacier2router will soon be exhausted. Actually, the memory of glacier2router is always not easy due to its inherent thread per connection model.
2) If My obove understanding is right, it is also impossible for glacier2router to be as a bridge to transfer any large data. I checked the diagram of "Wish: an Ultra Massive Online Game built with Ice", there is not a icepatch server. So I just feel curious how the wish to deal with the situation that when the game is upgraded then the players can upgrade their client program online. Maybe, there is a seperated server without using glacier2 to support downloading.
3) In our current project, after two months studying ice, I have almost decided to use glacier2router as the front end of our server. But I suddenly realize that it seems not feasible for it to transfer large data. I cried so hard :mad: .
Hope my worry is not necessary , or hope find a remedy.
4) I have learned so much knowledge from ice staff, especially about glacier2router. But I still advise that you can give a specification about the least thread stack size and the most connections the glacier2router can support since this configuration seems not dependent on the applications as Bernard once said.

Best regards
OrNot

Comments

  • marc
    marc Florida
    OrNot wrote:
    1) As I understand(I am not very sure :o ), the glacier2router will buffer the data from server. If the data is not large, such as in the chat demo,it is ok . However, If the data is from IcePatch server, the situation is very different. I think it seems impossible for glacier2router to buffer the large data ,say, 100M from icepatch,especially to deal with the concurrence issues. The memory of glacier2router will soon be exhausted. Actually, the memory of glacier2router is always not easy due to its inherent thread per connection model.

    First, Glacier2 can operate both in buffered and unbuffered mode. If you use Glacier2 for icepatch, I recommend no buffering, simply because it is not necessary.

    However, even if you switch buffering on, there is no problem, because IcePatch doesn't transfer the data in one huge request, but instead transfers data in several small chunks.

    I don't understand your comment about "the memory of glacier2router is always not easy due to its inherent thread per connection model". What is not easy? What does memory consumption have to do with the threading model?
    OrNot wrote:
    2) If My obove understanding is right, it is also impossible for glacier2router to be as a bridge to transfer any large data. I checked the diagram of "Wish: an Ultra Massive Online Game built with Ice", there is not a icepatch server. So I just feel curious how the wish to deal with the situation that when the game is upgraded then the players can upgrade their client program online. Maybe, there is a seperated server without using glacier2 to support downloading.

    We used IcePatch both with and without Glacier, and there is no problem with memory.
    OrNot wrote:
    3) In our current project, after two months studying ice, I have almost decided to use glacier2router as the front end of our server. But I suddenly realize that it seems not feasible for it to transfer large data. I cried so hard :mad: .
    Hope my worry is not necessary , or hope find a remedy.

    I don't think there is any reason not to use it. Just transfer reasonably sized chunks of data with each request. Transferring huge amounts of data in a single request is always a bad idea, with or without Glacier.
    OrNot wrote:
    4) I have learned so much knowledge from ice staff, especially about glacier2router. But I still advise that you can give a specification about the least thread stack size and the most connections the glacier2router can support since this configuration seems not dependent on the applications as Bernard once said.

    The stack size depends on your application. It's best if you try to experiment with the size to find out what minimum size still works for you. The number of connections is operating system dependent.

    I'm sorry, but we cannot be of further assistance regarding this topic as part of the free support here in this user forum. If you need more help, then you must purchase commercial support from us.
  • OrNot
    OrNot
    I'm sorry, but we cannot be of further assistance regarding this topic as part of the free support here in this user forum. If you need more help, then you must purchase commercial support from us.
    hi, Marc. :p . I feel kind of guilty since I asked more even after your generous and inspiring answers and what I can say only is to thank you . Our project is to implement a network administration software for our campus computer center. Ice is so great and is the right tool to develope it. So I have to try my best to learn it. Thank you again.
    However, even if you switch buffering on, there is no problem, because IcePatch doesn't transfer the data in one huge request, but instead transfers data in several small chunks.
    Very cool. This is what I want. we will simulate the methods used by icepatch to develop our embeded patch system.

    I don't understand your comment about "the memory of glacier2router is always not easy due to its inherent thread per connection model". What is not easy? What does memory consumption have to do with the threading model?
    I feel embarrassed about this question because I have asked it several times. :o. What I mainly worry about is that the more connections, the more memory consumtion and the server breaks down. I can not figure out how a server to deal with 8000 connections with even 128K thread stack size when the buffer mode is turned on. Of course I , a developer, can try the stack size to find a proper value,but it is realistic to ask the client without any ice knowlege to try and try until before the server break down? In the opinion of mine, It is better to give some advice such as " if the server has 2G memory, the least thread size is xxx, and the recommended size is xxx, if the server has 1 G , then ...." , At the same time , the connections most allowed may be advised. Even it is OS dependent , it is also possible to give a recommended value.
    So far as our project, I expect that I can tell the campus computer center that our software with a stack size set in advance can support at most 2000 connections with a server,say, 2G memory. Instead , I can not tell them that you can first set the value 256K, if connections inrease and your server breaks down, just set it to 128K.

    BTW: what's the thread stack size of the Wish(if not a commercial secret) ?
    The stack size depends on your application.
    I have asked this question in this thread http://www.zeroc.com/vbulletin/showthread.php?t=1555 . And I understand that Bernard is inclined to that the stack size does not depend on the application if my understanding is right. I also think so because It seems the stack size is only used by thread itself. Whether or not is not a small problem because it decides how the end users ,especially them without ice knowlege, will be involved into the ice-based software configurations. we have no rights to ask the client to know more about the stack size. So,hope getting further clarifying but not feel any compelling. Sorry for this question.
  • marc
    marc Florida
    OrNot wrote:
    I have asked this question in this thread http://www.zeroc.com/vbulletin/showthread.php?t=1555 . And I understand that Bernard is inclined to that the stack size does not depend on the application if my understanding is right. I also think so because It seems the stack size is only used by thread itself. Whether or not is not a small problem because it decides how the end users ,especially them without ice knowlege, be involved into the ice-based software configurations. we have no rights to ask the client to know more about the stack size. So,hope getting further clarifying but not feel any compelling. Sorry for this question.

    Hmm... yes, Bernard is right. The stack size does indeed not depend on the application. Sorry for the confusion.

    I recommend to simply set the stack size to somewhat less than the total virtual memory that you want Glacier2 to use, divided by the number of threads. If you have a 64-bit operating system, then this usually means that you can set it as large as you like (or just keep the default), because your total virtual memory is so large, that any thread size will do. If you have a 32-bit operating system, and let's say 1000 concurrent clients in unbuffered mode (meaning 1000 threads), and you want Glacier2 to use at most 2GB out of the total 4GB virtual memory available, then use less than 2GB / 1000 = 2MB.

Categories