Poniższe punkty są krytyczne dla prawidłowego działania programu w trybie rozgrywek.
Najważniejszym testem jest zdolność realizacji gry w komunikacji z
brokerem. Broker wywołuje programy grające zgodnie ze specyfikacją
podaną w warunkach zadania, więc jeśli program zachowuje się zgodnie z
tą specyfikacją, to powinien nawiązać poprawną komunikację z brokerem i
zrealizować poprawną rozgrywkę. Jest absolutnie niezbędne aby każdy
wykonał ten test przed oddaniem zadania. Należy: (1) skompilować
najnowszą wersję programu brokera (w tej chwili jest to wersja
202406071136), oraz (2) skompilować swój własny program, i zakładając,
że program brokera ma nazwę broker a własny program do gry nazwę
a.out, (3) należy wywołać:
./broker ./a.out ./a.out
Jeśli program jest poprawnie napisany to na wyjściu (dokładniej: na
wyjściu stderr) powinniśmy zobaczyć wyświetlony przez brokera przebieg
rozgrywki programu (samego ze sobą) zakończonej jakimś poprawnym
wynikiem.
Uwaga: jeśli nasz własny program generuje jakieś komunikaty na stdout
albo stderr to zobaczymy je od obu instancji naszego programu,
pomieszane na wyjściu z komunikatami brokera. Będzie to bardzo
nieczytelne, ale żadne z tych komunikatów nie wpływają na przebieg
rozgrywki.
Pojawiło się nieporozumienie dotyczące parametrów ip-address i
ip-port. W specyfikacji jest napisane, że te parametry są opcjonalne
i mają znaczenie tylko wtedy, gdy pierwszy parametr interface ma
wartość NET. Jest to nie do końca precyzyjne i najwyraźniej mylące.
Nie chcę teraz zmieniać specyfikacji, ale należy to rozumieć
następująco.
Parametry ip-address i ip-port są opcjonalne w tym sensie, że w
trybie GUI parametry ip-address i ip-port nie mają znaczenia i są
nieużywane. Natomiast w trybie NET parametry ip-address i ip-port
są obowiązkowe i w każdym wywołaniu programu oba muszą się pojawić. Co
prawda ip-address najczęściej (np. w moich rozgrywkach) będzie miał
wartość localhost, ale ip-port będzie za każdym razem miał określoną
wartość, i musi być podany, a więc ip-address też musi się pojawić.
Podana w specyfikacji zadania domyślna wartość 12345 dla ip-port nie
ma sensu.
To doprecyzowanie nie ma znaczenia dla programów, które prawidłowo odczytują i wykorzystują wszystkie parametry. Jednak pojawił się program, który ignoruje zadaną wartość portu i próbuje otworzyć połączenie na porcie 12345.
Problemy opisane poniżej są istotne dla programów wywoływanych w trybie nieinterakcyjnym, bez komunikacji z użytkownikiem. W systemach sterowania i automatyki taki tryb pracy programów jest bardzo typowy. Co prawda program brokera zostanie zabezpieczony przed programami, które nie podporządkują się poniższym zasadom, jednak ich znajomość i praktyczne stosowanie jest ważne dla ogólnej umiejętności programowania.
Ze względu na środowisko wywołania programu, i powyższe zachowanie,
programy do gry w warcaby wywołane w trybie NET nie powinny nic
wyświetlać na wyjściu stdout.
Jeśli chcemy obsłużyć w programie jakąś sytuację nieprzewidzianą, czyli
błąd, to program powinien przede wszystkim wygenerować odpowiedni
komunikat na wyjściu stderr. Jednak w takiej konfiguracji, w jakiej
te programy będą wywoływane, będzie niemożliwe stwierdzenie który z
procesów wyświetlił dany komunikat. Dlatego każdy komunikat wysyłany
przez program na stderr powinien zaczynać się od napisu: "...: " gdzie
w miejsce ... należy przekopiować wartość argv[0]. Spowoduje to, że
wszystkie komunikaty wyświetlane przez program będą się zaczynały od
nazwy z jaką ten program został wywołany (np. "./a.out") ale gdy w
danej grupie procesów będzie uruchomionych wiele procesów o różnych
nazwach, to będzie łatwo rozróżnić od którego procesu pochodzi dany
komunikat (broker będzie wywoływał programy studentów z różnymi nazwami,
pozwalającymi je zidentyfikować).