uftp client: sometimes strange behavior
Encrypted UDP based FTP with multicast
Brought to you by:
dennisbush
Menu
▾
▴
Hi again Dennis =)
client's version that im using:
sometimes i've seen in log something like that:
Im still using UFTP server -> Client and Client -> Proxy -> UFTP server (Proxy is for aggregation client's responses).
In the proxy's log:
Server's log:
But sometimes all went ok and nothing bad happen.
Maybe you may say something about? Appreciate your help.
It looks like the client never got the REG_CONF it was expecting from the server. It also appears that it never got a FILEINFO from the server with its ID in the client list. This seems to indicate that the server never got the REGISTER. What's in the server log for this session?
There is full log from server: https://dl.dropboxusercontent.com/u/21671126/aida-20150430-085224.log
I see that the client first received an ANNOUNCE with its name included at 08:52:28.263434. The server had finished the Announce phase at 08:52:27.680782 and the File Info phase finished at 08:52:27.936069, so it was too late for the client to start the session by the time it got the ANNOUNCE. It's possible that it got hung up doing a DNS lookup on the server's ID. You can disable this by passing -q to the client.
Something else that seems out of place, while not a huge problem, is that the clients are sending multiple REGISTERS even after the server sends a REG_CONF.
Can you run a test with just 2 or 3 receivers not using a proxy, and with logging set to 5 on both server and clients and post the logs? I'm curious to see how the timing is working out.
Hi,
running command:
whereis test_f_uftp_banuchka is a result of execution
Log from the server: https://dl.dropboxusercontent.com/u/21671126/banuchka_uftp_2015-05-05_1.log
Client's cloud24 log: https://dl.dropboxusercontent.com/u/21671126/cloud24_uftpd_2_send.log
Client's scripts25 log: https://dl.dropboxusercontent.com/u/21671126/scripts25_uftpd_2_send.log
images1: https://dl.dropboxusercontent.com/u/21671126/images1_uftpd_2_send.log
images2: https://dl.dropboxusercontent.com/u/21671126/images2_uftpd_2_send.log
images3: https://dl.dropboxusercontent.com/u/21671126/images3_uftpd_2_send.log
images4: https://dl.dropboxusercontent.com/u/21671126/images4_uftpd_2_send.log
This seems to be a different issue, perhaps related to the clients not receiving anything on the private multicast address. Check your multicast settings to make sure traffic is moving properly.
Try it again, this time adding a bogus client to the list so that the server sends the maximum number of ANNOUNCEs to try and prompt the clients to respond. Also, you can use a small file for this test, since it's not the data transfer part I'm concerned about.
Hi,
sorry for my mistake
Here is a new logs: https://dl.dropboxusercontent.com/u/21671126/uftp_sf.tar.xz
$ tree . ├── banuchka_uftp_2015-05-07.log ├── cloud24.ulan │ └── uftpd_sf.log ├── images1.ulan │ └── uftpd_sf.log ├── images2.ulan │ └── uftpd_sf.log ├── images3.ulan │ └── uftpd_sf.log └── scripts25.ulan └── uftpd_sf.logwhere "banuchka_uftp_2015-05-07.log" is a log from the server and client's logs is in their subdirs.
Run with
While this doesn't exhibit the issue of repeated REGISTERs in the original log or the delay in responding to the ANNOUNCEs, it does show that none of the clients received a REG_CONF and that it took them a while before they got a FILEINFO. I don't know what your network setup looks like, but if you're passing through one or more routers I suspect that there's a delay in setting up the private multicast address to pass through the routers.
If possible, place static routes in your routers for the public multicast address and the range of private multicast addresses you'll be using. That should help with that delay.
Regarding the delays in responding to the ANNOUNCEs, we probably need to run with the full set of receivers to recreated it, so go ahead and do that, with loogging turned up on just the few receivers from the last test. Then send me the server log and the logs of those clients.
do i need to set "-x 5" on the server side?
No, just the clients we're focusing on should be fine.
Here is a new portion of log files from morning's deployment process
https://dl.dropboxusercontent.com/u/21671126/uftp_sf_20150508.tar.xz
$ tree uftp_sf uftp_sf ├── aida-20150508-092310.log ├── cloud24.ulan │ └── uftp_27C18288.log ├── images1.ulan │ └── uftp_27C18288.log ├── images2.ulan │ └── uftp_27C18288.log ├── images3.ulan │ └── uftp_27C18288.log └── scripts25.ulan └── uftp_27C18288.logand there is a simple scheme of out network(from network dpt): https://dl.dropboxusercontent.com/u/21671126/network_map.png
Last edit: banuchka 2015-05-08
Alright, it seems that both this set of logs and the previous actually exhibit the same problem. In particular, I see that images1.ulan doesn't receive a REG_CONF until more than 500 ms after it gets the ANNOUNCE. This goes back to what I mentioned before, namely that it's taking a while for IGMP message to propagate while setting up the private multicast group. Also, I noticed that this client only received one of the three ANNOUNCE messages from the first set. I find it surprising that loss occurred at the very beginning of the session. I'm not sure if this is related as well.
I'm not too familiar with PIM, but it's possible it may be responsible for these delays. You'll probably need to tweak some settings on your routers to reduce the delays. Set up a packet trace on images1.ulan so you can see exactly what went in and out. You can do this with a small number of receivers and a small datafile (less than 1 MB) so that the trace file isn't too big. With that data in hand, you can figure out what adjustments you need to make.
Hi,
with tshark it looks like that:
Hi Dennis,
Greetings !!
We are trying to use UFTP for transferring large files across multiple location using satellite multicast . We are doing a test with 3 locations ,we are facing a strange problem for small files the transfer gets completed in most of the time but when we try for larger files >6GB we find at some or other location a disconnection & transfer aborts even when we have good connectivity.
We are using the following setting for transfer on Ubuntu 12.0 across all location.
Can you suggest anything which we are missing which is aborting the transfer . Is it due to license ? I will be obliged if you can give us some tips to resolve the same.
Thanks in advance.
Rgds
Sagar