modem duplex

As modems send and recv they trigger 'modem_message' events, the event system itself is using coroutine.yield() which implies a 'pause' in the active code. This brings the question of whether a modem could be sending data and simultaneously have the 'modem_message' event being pushed to it. My guess would be no unless it can use a queue to recv the events and only then would it work if it also supported time stamps for the event. So is a full duplex scenario even feasible?

you can send and receive simultaneously. at least I've never had problems events being dropped, because I was sending at the time of "arrival". The simulation of networking in ComputerCraft is actually in a higher level as duplex problems in the real world occur. So, you can't really compare it to full duplex. Full duplex is actually just there to avoid data corruption of interfering messages sent on the same medium(full-duplex actually has a sending and receiving medium) at the same time. In ComputerCraft you shouldn't get this problem, as the simulation is not that deep. If you send a modem message, it just generates an event with that data(doesn't even have to be a string) at all computers able of receiving it. Theres no such thing as a collision.

InDieTasten, on 18 July 2015 - 09:27 AM said:

you can send and receive simultaneously.

Truth be told, you can't.

The reason why is that all multi-tasking in ComputerCraft boils down to time-slicing - only one process is ever executed at once (and that's world-wide, mind you, within the scope of a MineCraft server).

That means if one of your systems is sending messages, all the other systems in the world are yielding, and therefore are not sending messages.

Bomb Bloke, on 18 July 2015 - 01:04 PM said:

Truth be told, you can't.

The reason why is that all multi-tasking in ComputerCraft boils down to time-slicing - only one process is ever executed at once (and that's world-wide, mind you, within the scope of a MineCraft server).

That means if one of your systems is sending messages, all the other systems in the world are yielding, and therefore are not sending messages.

I'm pretty sure this is limited not to the world, but for the computers able to receive the message in terms of range, network cable topology and opened channels(otherwise you wouldn't be able to run computers in a multiplayer environment. It's true to say, that an individual computer can only receive 20 events/second, meaning 20 modem_messages).
Also, time-slicing is happening, but the events will build up up until the next yield as far as I understand it. So you can practically do an os.pullEvent() on a modem_message and char event for example, and don't have to worry about a missing a modem_message, because you've pushed a key of alphanumeric value in the "same" time. In fact, pushing such a key would also cause a key event "simultaneously", so it's false to say they run in complete parallelism, but for the sake of understanding, you can call it simultaneously, as there's not really a time gap between those(only the order may be of interest as it may influence the state of your application based on how you design it) and the event queue doesn't care about it.

So events are never dropped, but depending on their implementation functions like sleep will ignore them afaik.

So to answer the question of OP, the event system already has this queue, which is the reason you can't miss the modem_message while you are for example sending a message, or writing to a file. but speaking of duplex just doesn't make sense, as you can have any number of hosts on the same cable not having any issues. even the full-duplex I know can handle this, as this is not it's scope, but the one of other devices, like a switch with each port then being able to run full-duplex. In computercraft, not that useful, as you don't need to prevent collisions

@BombBloke : I think I misunderstood what you were saying. I thought you were writing about the modem_messages and how they affect the yielding of computers. It is true, that all Computers are running in one linear process, where it's just jumping from one to the next, but the real sleeping is done, when it comes to receiving modem_messages. So it's untrue to say, that sending a modem_message will make every computer halt. They are already halted, but the receiving computers will hault even longer(till the next game tick) to actually receive it.

InDieTasten, on 18 July 2015 - 09:27 AM said:

you can send and receive simultaneously. at least I've never had problems events being dropped, because I was sending at the time of "arrival". The simulation of networking in ComputerCraft is actually in a higher level as duplex problems in the real world occur. So, you can't really compare it to full duplex. Full duplex is actually just there to avoid data corruption of interfering messages sent on the same medium(full-duplex actually has a sending and receiving medium) at the same time. In ComputerCraft you shouldn't get this problem, as the simulation is not that deep. If you send a modem message, it just generates an event with that data(doesn't even have to be a string) at all computers able of receiving it. Theres no such thing as a collision.

Full duplex was 'invented' because of the invention of the switch, in a previously typical bus topology all devices share the communications medium and thus share bandwidth and a collision domain since all devices shared the collision domain none could send or receive simultaneously. This is known as half duplex. Full duplex however is the opposite, each link to the switch is its own collision domain and therefore the bandwidth is not shared which allows for full capacity transmission on each link instead of sharing it with the entire segment as well as being able to send and receive simultaneously because no collisions can occur. This took the network industry by storm as it immediately effectively doubled the true speeds at which devices could communicate without error.
So, what you mean by this…

Full duplex is actually just there to avoid data corruption of interfering messages sent on the same medium(full-duplex actually has a sending and receiving medium) at the same time.

I have no clue because you're describing half duplex

InDieTasten, on 18 July 2015 - 03:07 PM said:

It's true to say, that an individual computer can only receive 20 events/second, meaning 20 modem_messages).

No it's not. You can pull events as fast as your actual computer can process. The only limit is 256 events in an event queue. Also, what Bomb Bloke said was completely true. You were probably thinking about timers, because they wait depending on ticks.

To OP: every computer has its own event queue. When an event happens its simply being put into that queue, nothing else. Whenever you yield the computer either returns an event from the event queue or waits for an event to happen. So you shouldn't be loosing any events.

MKlegoman357, on 18 July 2015 - 08:05 PM said:

InDieTasten, on 18 July 2015 - 03:07 PM said:

It's true to say, that an individual computer can only receive 20 events/second, meaning 20 modem_messages).

No it's not.

Well, at least I was never able to receive more than 20 modem_messages / second, and I don't think it was at the limit. I formulated the sentence a bit wrongly. I'm well aware that I can process as many events as I want restricted only by performance, but modem_messages are restricted to 20 aren't they. As I've said, I tested this months ago at a time, where someone was actually asking this in Ask a Pro.

And btw, i already corrected that in slight manner the post afterwards. My brain heap was all about the question(what it should be) and wasn't playing attention, that bomb blokes post didn't really have to do with the question at all, just pointing at the term simultaneously in my post ignoring everything around it.

jacky500, on 18 July 2015 - 06:21 PM said:

InDieTasten, on 18 July 2015 - 09:27 AM said:

you can send and receive simultaneously. at least I've never had problems events being dropped, because I was sending at the time of "arrival". The simulation of networking in ComputerCraft is actually in a higher level as duplex problems in the real world occur. So, you can't really compare it to full duplex. Full duplex is actually just there to avoid data corruption of interfering messages sent on the same medium(full-duplex actually has a sending and receiving medium) at the same time. In ComputerCraft you shouldn't get this problem, as the simulation is not that deep. If you send a modem message, it just generates an event with that data(doesn't even have to be a string) at all computers able of receiving it. Theres no such thing as a collision.

Full duplex was 'invented' because of the invention of the switch, in a previously typical bus topology all devices share the communications medium and thus share bandwidth and a collision domain since all devices shared the collision domain none could send or receive simultaneously. This is known as half duplex. Full duplex however is the opposite, each link to the switch is its own collision domain and therefore the bandwidth is not shared which allows for full capacity transmission on each link instead of sharing it with the entire segment as well as being able to send and receive simultaneously because no collisions can occur. This took the network industry by storm as it immediately effectively doubled the true speeds at which devices could communicate without error.
So, what you mean by this…

Full duplex is actually just there to avoid data corruption of interfering messages sent on the same medium(full-duplex actually has a sending and receiving medium) at the same time.

I have no clue because you're describing half duplex

If you read carefully, I'm describing the exact same thing as you do. It's solving the problem of "data corruption of interfering messages sent on the same medium" by using multiple mediums. Also, saying that it effectively doubled the speed is not true. You in normal sized networks, running switches in half-duplex mode wouldn't cut the bandwidth in half(remember, 1 full-duplex is 2 half-duplex). sometimes (when the source and destination are always the same) 2x half-duplex can even achieve higher bandwidths, although most of the time you would get like 40% increase by using full-duplex, depending on how often the role of sender and receiver switches. And I don't think you need to explain networking to the community. I'm pretty sure they all know what it basically does. I'm just wondering now, what the question is really about. There have been 3 answers to your question, but no feedback yet. At least I don't know what you are trying to do. It's too of a generic question. whats the context? whats the deal?

InDieTasten, on 18 July 2015 - 08:50 PM said:

The duplex does not determine the medium. In full or half duplex using Ethernet on twisted pair there is one sending pair (1,2) and one receiving pair (3.6) which has always supported the potential for sending and receiving simultaneously. I'll mention I put '' around "invented" in my previous post to reference this, meaning that all that actually happens for half -> full duplex is that CSMA/CD (Carrier Sense Multiple Access w/ Collision Detection) is disabled which allows it to send and receive simultaneously since the send function no longer loops back the frame onto the receiving pair. Also enabling full duplex does double the bandwidth because with half duplex you can only send or receive at any given time in either direction, with full duplex however, you can send or receive at the same time and the speed of the NIC remains constant since you are sending and receiving on different pairs which means you have equal bandwidth in either direction.

And I don't think you need to explain networking to the community.

I'm only trying to inform you, to help better your knowledge, the community is also welcome to take it however.

I'm just wondering now, what the question is really about. There have been 3 answers to your question, but no feedback yet. At least I don't know what you are trying to do. It's too of a generic question. whats the context? whats the deal?

I think Bomb Bloke's answer was of the most help but the question was simply is it possible to send and receive simultaneously despite the way that the event system functioned using coroutine.yield()

jacky500, on 18 July 2015 - 06:21 PM said:

Full duplex was 'invented' because of the invention of the switch, in a previously typical bus topology all devices share the communications medium and thus share bandwidth and a collision domain since all devices shared the collision domain none could send or receive simultaneously. This is known as half duplex. Full duplex however is the opposite, each link to the switch is its own collision domain and therefore the bandwidth is not shared which allows for full capacity transmission on each link instead of sharing it with the entire segment as well as being able to send and receive simultaneously because no collisions can occur.

Er, sort of. The nature of the collision domains defines whether you can, but not whether you are, using full or half duplex. Generally you'll be using the best the hardware allows, but you don't have to!

InDieTasten, on 18 July 2015 - 08:40 PM said:

but modem_messages are restricted to 20 aren't they. As I've said, I tested this months ago at a time, where someone was actually asking this in Ask a Pro.

Running this example script on a couple of modem-equipped systems, I get about a thousand messages per second (and if my processor were faster, I'd likely get more).

Like MKlegoman357, I strongly suspect you allowed the timer system to poison your results, as those events do always have to wait until at least the next server tick (of which there are 20 per second) before appearing in the event queue - even if you do os.startTimer(0)!

Bomb Bloke, on 19 July 2015 - 02:34 AM said:

Correct a switch can use either half or full but an Ethernet bus or hub can only use half and not full.