generative modeling for Rhino
Hello gHowl Team.
I am developing a C++ command line application that, among other things, wants to communicate with GH through UDP and I am considering using gHowl to do so.
So far I am able to send messages to the udp receiver (which I assume creates a winsocks server) by creating a client in my application and using the sendto() function.
My problem is I don't seem to be able to answer to the client's request from gHowl. I am using a UDP sender components to bradcast my responding message and this message is capturedd by the UDP receiver but not from my c++ client, which just keeps waiting for a message to come.
I have tested my application with other servers and It works.
Any clue on how I could get this working? Basically I need to send data into GH using an client on one IP and Port and answer to that client with more data.
Besides, could you explain a bit about the #pattern meaning in the UDP Sender - What means "ASCII Text (7) New line return [r+n] (14) ? What is the 7 and the 14?
Somehow I am not fully understanding the issue. I think you are able to send from your app, but not receive? I would need to know a bit more about the topology of the connection. What I think is maybe happening is that you might be trying to receive and send from the same port on your app. If your app is sending on the port, then you might run into troubles receiving on that port. Is your code setup to throw exceptions when you try to send or receive? It might be throwing a 'Socket already in use' exception? Are you doing this on the same machine?
If both clients (the UDP receiver in grasshopper and the other receiver in your C++ program) are simulanuously waiting for a message on the same port, and both clients are running on the same machine, only 1 client will get the packet that is send.
If this is the case, try to disable the UDP receiver in your grasshopper canvas.
If the 2 clients are not running on the same host, check the IP address of the sender (ff not set it uses localhost as default.
You mention that you want to broadcast the message. I guess that broadcast is supported, in that case use the broadcast address "255.255.255.255".
Concerning the #pattern: I would also like to know what the "7"and "14" mean....
Hi Rick. Thank you for your time and thoughts.
You say UDP receiver is a client. I am not very sure about this because, while doing tests, I set up a standalone UDP server in the same IP and Port that I provided to the component and all I got was a "Socket in use exception", so It seems to me that UDP receiver acts like a server and creates a socket.
Obviously, I can't disable my UDP receiver because then I won't be able to get data from my app, process it in GH and then send it back to my app, which is the purpose of all this mess.
I will keep on searching and testing and will come back to you if any solution arises.
As far as I have read about UDP, if you have a client and are able to send messages to a server, you should be able to receive messages from that server with the same connection socket. My code is based on these simple examples.
My code is not prepared to catch exceptions. It says nothing about socket already in use because I asume the UPD receiver component creates the socket as Server and my application binds to that socket as client so no one else tries to get that connection.
Of course, one option for me would be creating an app-side server and sending data to it from gHowl on another port but, as I just tried to understand sockets, I hoped everything could work with only one connection.
So Luis, could you confirm if UDP Receiver creates a socket server and if UDP Sender acts as a client? Maybe this webpage can help to solve our possible terminology differences:
Thank you very much, gHowl is fantastic!
In the MSDN definition, the class is System.Net.Sockets.UdpClient. There is no distinction apart that if you want to receive, you use receive methods, and if you want to send, you use send methods.
It seems the sender in your app and the UDP receiver in GH have are sharing the same port. I would chose two ports, one for each application. GH will listen for messages sent to its port from your app, and your app will listen to messages on its port sent by GH. You would give the UDP sender in GH the port for your app, and when you send messages from your app, they should be sending to the port given to the UDP Receiver in GH.
The (7), (14), and (8) deal with the bit size arrangement of the data to be sent. ASCII Text is a 7 bit character encoding http://msdn.microsoft.com/en-us/library/system.text.encoding.ascii(..., in the background the stream of doubles is working in an 8-bit array. This is a part of gHowl we have also been meaning to revamp in order to make sending of more specific data types a possibility. Hopefully we can tackle it in the next revision.
The situation in gHowl does not match a "typical" server:
"Typical" client->server communication works as follows:
1) the client creates a socket and binds it to the address and port of the server. The OS will select a free number for the port of the client (the ip-header of the ip-packet has to contain the ip adresses and ports of the source and destination). Data can now be sent through the socket.
2) the server has already created a server-socket and waits for data. When data arives, it will get the ip-address and port number of the source from the received packet. It will use this info to send a reply back.
Now, the gHowl UDPReceiver and UDPSender components each create a socket. There is no information exchange about the IP-address and port of the host between the UDPReceive and UDPSender. For sending data back to the originator, UDPSender needs to an IP and port, which is set manualy (at least in the examples that I looked at). Both ip adddress and port are although present in the packet that the UDPReiceiver received. This info is not used however. The result is that the grasshopper application needs to know the address of the clients...
Effectively, the gHowl approach uses 2 pair of sockets for communucation. A typical client-server uses only 1 pair.
I see 2 possible ways how gHowls UDP could be extended for this.
I think 2) would be the best solution for implementing a "true" server (which uses only 1 socket and no hardcoded client addresses). Then, a grasshopper app that needs to implement server functionality only uses the UDPReciver (which might be renamed to UDPServer) component. A grasshopper that needs to access other servers only needs the UDPSender object...
Luis, what do you think?
What you propose is certainly possible. We will look into it to see when it would be possible to implement. Currently I am working on rewriting some other components in order to release an update mid September. If there is time, then we will try to fit this in.
Actually, just tried something and it seems this should not be so difficult. Would you to be willing to test this out and let us know if it is doing what you are looking for? There are probably a few bugs to work out. If so, send me a message with your email and I will send you the prototype.
Sure, I just PMed you.
Thanks a lot Luis!