1: I don't necessarily think exit should end in \n, depends a bit on other choices though. this issue is about that \n is missing between all messages, it never gets sent ever.

2,3: does such a guarantee actually exist? to my (flawed) understanding the kernel will split it into packets however it pleases. a send call is not a frame, not even with short bytestrings.

4: start server exactly once, attempt to connect on both ports and see which sticks and continue to use that one without closing it

6: if it's not about framing then it probably shouldn't act on frames. so no \n at all. or if it is to act on frames, then they need to actually be used. one or the other. if the \n have meaning then there has to be a buffer. if there's no buffer, then \n have no purpose and mentioning them in the description becomes weird.

7: solver shouldn't debug test code or even have to question it. if the tests need more logic to behave well then so be it.

I'm also not at all convinced by that exit check being correct. I'd be looking for some kind of polling with a timeout here, continuing to call recv until it gives an empty response for example. I'm not happy with things that merely "seem to work"

waiting on solution threads to exit also needs timeouts. the user isn't told this is happening, so it needs to be well behaved. alternatively, don't wait, and change them to daemon threads, that way there isn't a hidden unspecified test that times out on fail.

hi hi, I got a bit of time to take a look.
ill go one by one if you don't mind, here is my current fork: https://www.codewars.com/kumite/684460b1f26fb0ebd9a46199?sel=684460b1f26fb0ebd9a46199

1: I looked back and you were right, the exit does not come with a \n which makes it hard to use. I have added the \n to the exit.

2: the issue here stems back to the exit. I was trying to be fancy and use TCP protocol guerentees to allow new socket programers (which was the target audiance of the kata) to use the much simpler "if a.recv(1024) == 'exit'" rather than having to use some buffer. I have added the guerentee that the exit massage will come with a \n which will fix that issue (although it will sadly invalidate a lot of solutions which is why I didn't do it before.)

3: again you are right, I added the framing support to the test, although the only case I will ever use it is if you add sleeps in the middle of your massage as everything I send (and therefor should be sent back) is short enough to fit into a single TCP packate :P

4: yea, the shim is ugly. but sadly I don't know of a nicer way to implement it... the original kata descryption required port 80 rather than 1111 which was problematic... ifg you have a suggestion im open to it. I canalso see just removing it altogether as im changing the requirements in this iteration by adding the \n to the exit massage.

5: in this case, not likely to matter. but I added in a sleep there as well for good messure.

6: you are right in theory, but the main point of the kata is not actually the framing. I much prefer this kata as a first time playing with sockets and letting the user have a nice moment where it works, the framing is a neccessery evil. in reality the tests are made specificaly so that any messeage I or the user send can fit within a single TCP packet.

7: sadly the timeouts happen as a result of the nature of socket katas. if the user runs a recv when there is no data to be recived there is not much difference than running a while True: pass
I tried a few things when I first wrote this kata but ended up deciding against adding the timing failiers as they end up very dirty.

overall I wouldn't write this kata like this had I been writing it today. but I think this new fork is at least servicable :D
please take a look, I will prob republish around monday if no more suggestions arise.

My idea of valid issue is whether I can reproduce it from the description. I should probably say THAT instead. There are obviously things to fix.

If it's your most recently submitted code that you refer to as your code then my understanding is that you have two servers on the same port, with connections being distributed between them. So if the first one ends up getting the connection then the second one never ends up receiving exit and the tests join on that thread so that'll be what times out (aside when the tests fail to send anything at all due to 0 length words which also causes timeout) (and aside from join it would also timeout because they're non-daemon threads - preventing the process from exiting even if the tests have run to end)

I've been thinking about whether this kata is fixable, what trips me up is what to do about the incorrect framing usage because that's a significant thing that needs to change about the kata design - either remove it to keep it simple or fix the inputdata and add tests for framing. Either one would break nearly all current solutions. I need an adult.

Re the issue not being valid, completely accept that something wrong in my code may be the issue, and that in itself is clearly not an issue with the Kata. It was more the fact that previously submitted solutions were also failing which lead me to flag the issue.

Having taken a step back and looked at your (considerably more extensive) analysis, I guess that the issue was something in my code not recognising the exit condition, meaning that one instance was still bound to the socket when the next test started.

issue 1:

the python tests do not send '\n' to separate messages, which it promises to do. (this leads to kata timeout when 0 bytes are sent) (this also means there will never be a frame starting with b"exit" as the previous frame is not terminated with \n

issue 2:

tests may (unlikely, admittedly) generate messages starting with the bytes b"exit", for example: b"exitabcd\n" (\n would currently not be there but it's supposed to be)

correct behaviour for the server/solution is to shut down because no further bytes are expected after b"exit" as description says this is not followed by \n

issue 3:

the tests ignore framing when receiving, they don't continue to read until receiving the delimiter '\n' before doing their == comparison. it may receive only part of the frame, the server/solution may for example call send for each individual byte, which would be a correct thing to do.

issue 4:

the server is started twice. if the compatibility shim wants to try two ports it should still only start once as connecting to the wrong port won't be seen by the server anyway. this is somewhat harmless in most cases but it results in a traceback being printed when the second one fails to bind

issue 5:

tests attempt to connect immediately after starting server thread. that socket may still be closed at that time.

in the case of old solutions using port 80, the server may also fail to start due to having already been opened and closed immediately before and the socket may still be considered in use

issue 6:

I would argue that message framing should be tested. the comment about short strings should be removed as irrelevant as the framing is determined by '\n' separators.

this can be done by calling send several times in a row without \n, possibly with short delays between and maybe altering socket settings to ensure they're sent immediately so that the server is very likely to have to call recv multiple times. likewise, multiple frames can be sent in a single send call

yes, this makes the solution far more complicated than what is probably expected! but is it supposed to be correct or no?

issue 7:

unexplained timeouts from joining threads and blocking send/recv calls - it's not ok for timeouts to happen in the test code

I'm sure there are more problems, I'm not familiar with socket programming so there's lots I wouldn't spot.

I like the idea of a socket kata though ..

mine times out when the test code "sends" an empty bytestring. which isn't to spec, and I'm guessing might be a no-op so it actually didn't send anything then expects a response

this is due to word length being random.randint(0,100) (1 in 101 chance to be empty)

I guess that's also the reason for \n. except it doesn't do that.

BTW: your issue isn't exactly valid since it doesn't say what it is failing to pass or why it fails. it doesn't describe a problem with the kata. except for the part about calling the solution function twice. but that probably isnt't the issue you're having due to one harmlessly crashing and the other continuing to exist.

I'd time out sometimes.

and there's a (poor) compatibility shim which starts another server. but I'd like to think that the second server to start would harmlessly crash, I don't see how that would cause a timeout.

it seems to me like it's test.assert_equals that doesn't finish. which is.. uhm. why..

aside from that, it also doesn't terminate messages with \n as it promises. not sure why it promises that but. would be nice if that matched up.

and tests aren't inside its

Had issues getting a solution to work (Python), it appears that the call to the function is re-entrant, in that previous tests do not close down the socket and hence there is still a server bound to the same port.

Forfeited and tried other solutions - including the more recent ones - and they too show the same issues.

The symbol is called an asterisk btw.

I thought it would be called the same here. I'm not an english speaker, literally I learned that word a few days ago that comment. I look it up and your right, even when it is the same symbol has not the same name.

Idk from a quick google it does not appear to do the same thing in powershell at all

Idk in powershell those are called wildcards.

to clarify: this only happens with the Cuban Peso (CUP) which has denominations [1, 3, 5, 10, 20, 50, 100]. all other currencies seem to be
canonical

Should you have the notes of denomination 1, 3 and 5 available with a target of 6, there are two ways of making the total with the same (minimal) number of notes - 1 + 5 or 3 + 3. It appears that the tests only allow 3 + 3 and not 1 + 5 despite the same number of notes being used.
Suggest that either the text specifies that the number of denominations should also be minimal, or the tests are altered to accept either solution.

.