Hi Marcus :-)
thank you for your great detailed explanation. Thats great !
Which means that the script setting up your flow graph just pauses for as long as it waits for the first socket to get its connection set up; the second socket is not in listening mode, yet, at this point. So youre doing everything right, its just so that your second tcp server isnt even created before the first one connects!
Mhh ok. But how i can detect which TCP port i have to connect first and second from the TCP client . if iam working with different ports on different TCP sink server blocks ?
If your application doesnt scream for performance:
What is performance for you ? :-)
You might just want to use gr_modtool to create a python source, let that blocks constructor set up a socket where you call sock.listen(), and give that block a start(self) method, which calls sock.accept, and stores the returned connected socket in a property of the block; work() would then write to that socket. Something like [3]
Yes, i understand you in principle. I will try out this and go in more detail later.
cheers,
Andy
Gesendet:Dienstag, 12. Mai 2015 um 13:06 Uhr
Von:Marcus Mller marcus.muel...@ettus.com
An:discuss-gnuradio@gnu.org
Betreff:Re: [Discuss-gnuradio] Problem TCP blocks
Hi Andy,
oh yes, I dont like that block ;) but Im happy its there.
So the problem lies in the way this block is structured, and how GNU Radio runs:
tcp_sink is just a hier block -- its nothing but a small wrapper around the file_descriptor_sink[1]. The cool thing about sockets is that you can, as soon as you have a connection, get a file descriptor for that connection and read and write from/to it, just like a file.
So tcp_sink just sets up a listening socket, and as soon as that connects, it uses the resulting file descriptor [2] to set up a file_descriptor_sink.
That is all nice -- but: this means that the constructor of tcp_sink blocks for as long as it takes till someone connects to this socket.
Which means that the script setting up your flow graph just pauses for as long as it waits for the first socket to get its connection set up; the second socket is not in listening mode, yet, at this point. So youre doing everything right, its just so that your second tcp server isnt even created before the first one connects!
In principle, this is something youd avoid; waiting for sockets to connect is typically the job of a gr::block::start() method rather than a gr::hier_block2s constructor, for exactly this reason. However, tcp_sink is there for historical reasons, and its mightily handy in many cases.
If your application doesnt scream for performance:
You might just want to use gr_modtool to create a python source, let that blocks constructor set up a socket where you call sock.listen(), and give that block a start(self) method, which calls sock.accept, and stores the returned connected socket in a property of the block; work() would then write to that socket. Something like [3]
def start(self):
Block start method, called when user calls tb.run/tb.start
self.connection, _ = self.listener.accept()
def stop(self):
self.connection.close()
self.listener.close()
def work(self, input_items, output_items):
in0 = input_items[0]
nbytes = len(in0)*self.itemsize
nnext = nbytes // self.itemsize * self.itemsize
last_pos = 0
sent = 0
remaining = nbytes
rawbuffer = in0.data
while nnext:
sent = self.connection.send(rawbuffer[last_pos:last_pos+nnext]) #um, yeah.
if not sent: ## we couldnt send a single byte -- connection is dead
self.connection.close()
return -1 ## Were done.
remaining -= sent
last_pos += sent
nnext = remaining // self.itemsize * self.itemsize # to make sure we only send whole items
return sent // self.itemsize
[1] http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1file__descriptor__sink.html
[2] https://github.com/gnuradio/gnuradio/blob/master/grc/grc_gnuradio/blks2/tcp.py#L70
[3] https://github.com/marcusmueller/gr-tcp/blob/master/python/tcp_sink.py really, just wrote this in a hurry. didnt even care to syntax check. for illustration purposes only.
On 05/12/2015 10:38 AM, Andreas Ladanyi wrote:
Hi,
iam trying to setup a grc project with 2 TCP sinks server blocks each with own TCP port but both TCP blocks with the same IP. So i want to open 2 different TCP Ports at the same host and same IP. At the other grc project iam trying to setup 2 TCP source client blocks which connect to the sockets from the first grc project.
nmap tells me that only one port on the server side is open and the other server port is closed. iptables is down. So iam wondering that it isnt possible to get both ports open. Iam testing this scenario on the same host system. Do i understand something wrong in GRC / Python socket concept ?
cheers,
Andy
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
