Ethernet server architecture (was dupping message data)

>
> [dave@computone.com (David Johnson) writes:]
>
> >Normally packets are sent up in a STREAMS environment asynchronously to the
> >modules above. They process them and send them to the STREAM head which
> >holds them for the user. However, in the server model, how can the TCP
> >module keep a pending receive in the Ethernet server and still service other
> >write requests from above?
>
> Well, the simplest way would be to launch another thread within the
> TCP process (see tfork(), more comments below), have him forever post
> reads, then requeue the responses to the TCP queue. Something like:
>
> User program Ethernet (read)
> | |
> |<----------+ |
> V ^ V
> +----+-----------+---+-+
> | thread1 thread2|
> | TCP server |
> +----+-----------------+
> |
> V
> Ethernet (write)
>
> So thread1 would do all the "real" work, with thread2 just gather
> packets and mixing them onto the single queue of thread1. thread1
> reads requests and ether packets, and generates responses upwards
> as well as transmitted packets downwards.
>
> If the ethernet driver tended to block transmit requests, you might
> even use a third thread to do the writes to ethernet. This would allow
> thread1 to continue running while writes were queued up and blocked.
>
> Now, some comments concerning threading. tfork() exists, and works. I
> use it a little, but am considering adding a second parameter. The
> existing parameter specifies where the thread should start running
> at (there are good reasons to do this instead of UNIX sementics for
> fork()); I think I should add a second parameter which is passed as
> the single argument on the stack to the new thread.
>
> I also know that the microkernel will need to offer some sort of
> semaphore facility to help threads coordinate, but haven't added it
> yet. I have a pretty good idea of what a multi-threaded multiprocessor
> kernel environment is like (I did UNIX kernel work at Sequent), but
> such an environment is very difficult, and I've been holding off
> implementing something until I felt I better understood a multi-
> threaded server process environment. Discussions like this help!
>
> Andy
>

Thanks for the info.

Since I am just doing the Ethernet (NE2000) driver presently, I think the
above information gives me enough to get this level of code working
properly. I hope to get packets moving by sometime next week considering
my current status.

I'll worry about multi-threading and coordination once I get this server
going.

If anyone has any other suggestions or comments on the architecture,
please let me know.

dave
Received on Wed Oct 13 14:36:31 1993