Fixing resolver starts taking long, sorry for that. Just want to tell that the progress is there. Yesterday i cleaned up several small claimed things (CLI tools say nothing when started without kernel running, now report about it), finished with cleaning up WaitSelect() code so as it doesn't leave dangling signals any more, installed DNS server on my Win95 box and started last remote tests. Imagine how upset i was when saw that even pinging remote host hangs. With localhost everything worked fine.
I began to investigate the issue, found one signal loss, fixed it, things went a bit better, now i could BREAK remote ping but still couldn't get any reply from the remote machine. Kernel hang up after this and was unable to quit. I panicked a bit, this totally prevented me from any following success.
Today at work i investigated the code one more time and compared with original AROSTCP. Good news: i think i found it. There is one more sleep function i didn't notice before, i didn't touch it and it relies on broken timer behaviour. I really hope this is the right place (90% of probability in fact because my fix in fact is simple - just reordered BeginIO() and AbortIO() into a proper sequence).
Hmmm... Seems like this thread turns into blog... Well...
Anyway, v0.4 will be stable. The more time i spend on it the better it will be. I also expect to bump bsdsocket.library version to 4 on saturday and rebiuld usergroup.library (i re-decided to port existing code, credential.resource is not so bad idea as it looks at a glance, it is anyway required as a global storage area since the library itself can be expunged from the memory at any moment). So hold on, v0.4 is expected to be a major upgrade. Probably it will even fit into Genesis environment as a kernel replacement, so you'll be able to start using it in everyday work!

Very nice work Sonic. Keep it up! MorphOS is getting more and more useable everyday now. Thanks!... Will be nice seeing the final result someday :)


Regards,
Michal

I hate crud like that in code. great work sonic and thanx for the updates. Look forward to seeign the work =)

I've been using ezTcp for some days now, and it works surprisingly
stable. I am getting pretty slow transfers on my LAN compared to
Genesis, though (~2.5mb/sec compared to ~6mb/sec over FTP with ATC).

Anyway, keep up the good work, Sonic. Looking forward to 0.4

I've just uploaded v0.4, waiting for the approval.
No usergroup.library yet, but all other items from TODO are cleared! It's all done!
Of course, TODO is not empty, more issues were discovered, but this is already a next stage.

@ Sonic

Good to see how this is going on, really GREAT WORK!

Keep it going.

Regards
Christoph

Whoop there it is!

Same location as before:

https://morph.zone/modules/mydownloads/singlefile.php?lid=334

I've studied code of usergroup.library and i think i know why Samba runs well on Miami and crashed on AmiTCP.
usergroup.library is a very crude weird hack, very quickly written, it's totally non-reentrable. If more than one process calls it at the same time it screws up.

Hi Sonic and good work again!
HTTPResume now works, but JabberWocky still does not work. It always says "Connecting.." and nothing more.

Quote:
Nice to hear
Quote:
AFAIK JabberWocky uses ixemul.library which will enable networking only if usergroup.library is present together with bsdsocket.library.
I am working on it. Will be there in v0.5.

I'm glad to announce that i found the problem which prevents JabberWocky from working with ezTCP. The problem is very easy to fix and it will be fixed in next version. The source of the bug is socket creation function which sets socket owner to NULL instead of caller task. This leads to ignoring any asynchronous socket notification.
v0.5 probably will still not contain usergroup.library since it seems to take a bit long, but will contain this fix along with restored WaitSelect() function. I'll release it ASAP because i consider the problem to be critical.

Well, I must say it works good. Beside Jabberwocky I have also problem with AmiNetRadio and Shoutcast-Streams. I got the Message "Wed Sep 28 00:06:32 2005 [crit ]: SBTC_SIGEVENTMASK tag item is not implemented". Will this be fixed with 0.5 also?

Oh, and I have problems while trying to access http://67665.rapidforum.com/ with the DNS.

[ Edited by DJBase on 2005/9/28 3:20 ]

Quote:
What exactly application cause this? This is not the same as jabberwocky problem, this means that the application uses features specific to bsdsocket v4. They are not implemented yet, these calls are just logged in order to make easier to discover them and prevent crashes. This requires some more efforts and not so fast to implement, but okay, i'll look what can be done right now. Probably quick partial implementation enough to run requested application is possble.
Quote:
What exactly problem? Host not found? Something else? I have a guess that numbers in the beginning are not interpreted correctly, will also test.

P. S. ezTCP 0.5 is waiting for the approval.

The stupid problem is isolated and will be fixed in next release. Currently hostname can't begin with a digit, if it does it is treated as a plain IP and, i guess, resolves to some wrong IP.

ezTCP 0.5 for grabs:

https://morph.zone/modules/mydownloads/singlefile.php?lid=334

(I really should just place this url into my signature )

Quote:

Well, it seems it can't connect or receive data. I will check with 0.5 later. Maybe it works now.

Jabberwocky works with 0.5 now.

Unfortunately for now this program will not work. As i said before, it requires new function which became availible only in AmiTCP v4 and Miami. A message "... not implemented" in the syslog tells about it. Current kernel does not contain this function despite that it reports that is is v4. This function needs to be added. I will try to do it after finishing usergroup.library (already 50% is done), it can turn into rather significant amount of work and unfortunately will kick me out of the timeline again.

I've been too lazy to try this yet, but it's been very cool watching it develop (I like the constant updates!).

Actually, there are a LOT of cool things happening for MorphOS right now!

I think it's about time I gave exTCP a try!

Anyone tested speed of this stack ?

I tested with copying morphos145pup.iso(27megs) from
mounted SMBFS share from the pc, in a 100mbit network,
machines is right next to eachother with a switch between.
Copying morphos145pup.iso to ram: took 52 seconds.
thats about 519kb per second. Shouldnt it be like
10-15 times faster ?

on emulated miamidx its around 3MB/s


[ Edited by catohagen on 2005/9/28 17:36 ]

If it means basic support for things that we expect to have in a TCP/IP stack, we could always put a vote up to allow a little more time more time. The reason I say "vote" is that I do not feel that I should arbitrarily decree a change on something this important.

Hi,

After surfing a few graphic heavy sites, it stops working
and in log:

Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [err ]: sana_read (eth): not enough mbufs
Wed Sep 28 21:49:40 2005 [err ]: m_alloc: max amount of memory already used (255120 bytes).
Wed Sep 28 21:49:40 2005 [warn ]: 23 log messages lost (total 0 lost)

Quote:
Nice. Not a bug, probably one more mis-feature. It's limit of memory for SANA-II buffers. Try inserting "MBUF_CONF MAXMEM=1024" into general.config. This option increases the limit up to 1 MB (default is 256 kb). Try playing with this value, may be you'll find more optimal one.
There are two ways: either simply increase the limit or change the default to "no limit". Probably i'll try the second one.

About speed: there are options TCPSND=<nbytes> and TCPRECV=<nbytes>, they set TCP buffer size for sending and receiving respectively. Default is 8192 (8 kb). I remember doubling this value improved the speed significantly for m68k AmiTCP. Here should be the same.

Quote:

Where should I set theese?

Hi all,

Encourage the ezTCP stack, today thursday 29 september, I donate $225
!

grtz Amigaharry alias Tom Duin

Visit my Amiga/Pegasos page at:
http://www.angelfire.com/amiga/ex