You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(10) |
May
(14) |
Jun
|
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
From: stanislav s. <sha...@in...> - 2005-11-07 16:49:19
|
iv...@cs... (Ivan Beschastnikh) writes: > I think there is a timelag between the cvs that i check into and the > anonymous cvs, so if you can, check out from the cvs with your > username. The lag is up to an hour, I'm told. I don't know on which minute of the hour rsync is supposed to run. Steven, If you'd like an account on cvs.internet2.edu, send me your SSH key and I'll have one set up for you. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ .signature: I/O Error |
From: <iv...@cs...> - 2005-11-07 07:29:58
|
On Sun, Nov 06, 2005 at 07:38:31PM -0600, Steven Senger wrote: > Ivan, > > After some travel and miscellaneous distractions I'm back to working > with VFer. I just checked out the code you have on the internet2 cvs. > Is this the version I should be working with? I've just tried the > test_sndfile/test_rcvfile on Darwin. The send side seems to transfer > the file and completes but the recv side never terminates. I can send > you the traces if that would be useful. Steve, Yes, your should use the version in I2's cvs. I fixed some more bugs tonight and am working on the timeout issue. Currently the problem is that the sender in effect enqueues the data and doesn't know when it has been transfered. For this reason test_sndfile.c has a sleep() call at the end of file reading\sending loop- to make sure that the data will be transferred before calling vfer_close(). There are two ways to fix this i think: 1. make vfer_send() block until the data is delivered or dropped due to reliability function on receiver side. This is easiest to implement but it doesn't make sense as the client shouldn't be burdened with waiting. 2. create a function to test amount of data still enqueued and sleep and poll that function. This is like (3) only less elegant. 3. Get vfer_select() working so that instead of sender timing out, let the receiver call vfer_select() with reasonable timeout to check if the socket is readable, and upon timeout close the connection. The sender will also call vfer_select() on the socket testing if socket is writable or has an exception (with unlimited timeout value), and when the receiver closes the connection, the sender will wake up and quit. I'm working on #3. By the way, in order to simulate data loss, i had code that would randomly drop every 2nd data packet. This was in the CVS before a couple of minutes ago, so to get better results, you might want to check out a new version + there were numerous bug fixes. I think there is a timelag between the cvs that i check into and the anonymous cvs, so if you can, check out from the cvs with your username. thanks! ivan. |
From: <iv...@cs...> - 2005-11-04 23:38:18
|
testing mailing list -- Ivan Beschastnikh <iv...@uc...> http://people.cs.uchicago.edu/~ivan/website/ |