[Gmsh] feature request: gmsh reads input from TCP port
Christophe Geuzaine
cag32 at case.edu
Mon Mar 13 22:27:26 CET 2006
Al Danial wrote:
> hi Christophe,
>
> I played with the TCP connection code for a couple of hours
> and have found running the code on a single Linux machine to
> work well--very cool.
>
> Running with two machines was more difficult. Here's my setup:
> - Linux machine at 198.168.1.101 on which I built v1.64.0 from source
> - Windows XP machine at 198.168.1.103 using the binary of v1.64.0 from
> your web site. Also has CygWin installed.
>
> First I made sure the Windows firewalling was disabled and did some
> tests with netcat going from Linux to Windows:
>
> CygWin> nc -l -p 44122
> Linux > cat cone.geo | nc 192.168.1.103 44122
>
> The cone.geo file was transferred from the Linux box to the Windows
> box just fine; the CygWin terminal window STDOUT showed the contents
> of the cone.geo file. I then killed netcat on both machines by
> sending ctrl-c from Linux.
>
> Next on the Windows box I started gmsh with Options/Solver
> socket name = 192.168.1.103:44122 and checked "Always listen..."
>
> On the Linux side once again I did "cat cone.geo | nc 192.168.1.103 44122"
> and this caused gmsh on Windows to crash. I figured I'd better go
It shouldn't crash, but it's normal that it doesn't work: you cannot
just send data on the socket--you have to follow Gmsh's solver protocol.
(That's what GmshClient.h is there for. Basically, the data is sent with
headers explaining the nature of what is sent next.)
> back to the canned demo so I modified interactive.cpp like so
> sprintf(socket, "192.168.1.103:44122");
> then ran the interactive method but it wasn't able to connect:
> Unable to connect to Gmsh.
> I modified the code to print out the reason it failed to connect:
> printf("Unable to connect to Gmsh: %d\n", _client.Connect(socket));
> and got back the value -2
> Unable to connect to Gmsh: -2
That's more like it ;-)
>
> I then tried the "cat cone.geo | nc ..." again but this time gmsh just
> ignored it. The gmsh message window said
> Warning : Failed to receive body on socket: aborting
> Info : Client disconnected: starting new connection
That's pretty good actually: it means that it received a header
(probably just lucky to get a number that is in the protocol), but
didn't get the associated data.
>
> For some reason I was initially able to send something between Linux
> and gmsh on Windows but it isn't repeatable; all subsequent attempts
> failed. Next I will try going from Windows to Linux, will post my
> findings. -- Al
>
Sounds good. I've only had a chance to test all this stuff on "single"
machines, so your tests will be useful.
>
>
> On 3/10/06, Christophe Geuzaine <cag32 at case.edu> wrote:
>> Al Danial wrote:
>>> The examples in utils/solvers/* show how one might tie an external
>>> solver to gmsh. From what I can tell, this scheme means gmsh and
>>> the external solver need to run on the same machine for the socket
>>> communication to work.
>>>
>>> What would be really nice is the capability to run gmsh on another
>>> computer on a network then send it commands over TCP. You'd start
>>> gmsh on Machine_A with something like
>>>
>>> gmsh -p 19000
>>>
>>> which says "wait for commands on port 19000", then from another
>>> computer, Machine_B, you'd connect to Machine_A's port 19000 and
>>> send it strings like
>>>
>>> "lc = 0.009;"
>>> "Point(1) = {0, 0, 0, 9.e-1 * lc};"
>>> "Point(2) = {.1, 0, 0, lc} ;"
>>> "Point(3) = {.1, .3, 0, lc} ;"
>>> "Point(4) = {0, .3, 0, lc} ;"
>>> "Line(1) = {1,2} ;"
>>> "Line(2) = {3,2} ;"
>>> "Line(3) = {3,4} ;"
>>> "Line(4) = {4,1} ;"
>>>
>>> (lines from t1.geo for example). In other words, rather than reading
>>> input from a .geo file, in server mode gmsh would read input from a
>>> port. The two machines merely need to be on the same network; don't
>>> need to share a file system (or operating system for that matter).
>>>
>>> The primary benefit is that you could run gmsh on a computer that has
>>> optimal graphics hardware--and tied to a massive screen in a conference
>>> room perhaps--while running the solver on a cluster or some other
>>> computer with beefy CPU's but little in the way of graphics.
>>>
>> Al - If you're still interested in this stuff, give version 1.64 a try:
>>
>> - select "Always listen to incoming connections" in Options->Solver
>>
>> - compile utils/solver/c++/interactive.cpp (it's a small test program
>> that shows off some of the new features of the solver interface in the
>> form of a command-line "Gmsh remote-control")
>>
>> (You can use a TCP/IP socket instead of a Unix socket by replacing
>> ".gmshsock" with e.g. "127.0.0.1:44122" in Solver->Options and in
>> interactive.cpp.)
>>
>> Take care,
>>
>> Christophe
>>
>>
>>
>>> I can provide demo client/server TCP code if there's a possibility
>>> that this request might be implemented. -- Al
>>>
>>> _______________________________________________
>>> gmsh mailing list
>>> gmsh at geuz.org
>>> http://www.geuz.org/mailman/listinfo/gmsh
>>>
>>>
>>
>> --
>> Christophe Geuzaine
>> Assistant Professor, Case Western Reserve University, Mathematics
>> http://www.case.edu/artsci/math/geuzaine
>>
>
--
Christophe Geuzaine
Assistant Professor, Case Western Reserve University, Mathematics
http://www.case.edu/artsci/math/geuzaine